Configure how SSH runs on the server for better security.
This is explained in sshdconfig manual (man sshdconfig): ClientAliveInterval. Sets a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client. Ssh (1) obtains configuration data from the following sources in the following order: 1. Command-line options 2. User's configuration file (/.ssh/config) 3. System-wide configuration file (/etc/ssh/sshconfig) For each parameter, the first obtained value will be used. F configfile Specifies the path of the server configuration file. By default, /etc/ssh/sshdconfig is used.-g logingrace Specifies how quickly users must authenticate themselves after opening a connection to the SSH server. The default is 120 seconds, but this can be changed in the server configuration file. Configuring SSHD on the Server Configure how SSH runs on the server for better security. We'll log into a server and edit the /etc/ssh/sshdconfig file, to change how users can use SSH to log into the server from remote locations.
We'll log into a server and edit the /etc/ssh/sshd_config file, to change how users can use SSH to log into the server from remote locations.We previously have used our local ~/.ssh/config file to easily log into a server. Let's now see some SSH options on the remote server, to see how we can affect who can log in and how.
SSH configuration is generally found in /etc/ssh/sshd_config.
Change SSH Port
We can change the port users use to login away from port 22.
Change the Port option to something other than 22:
Then restart SSH:
We can then try to login from our local computer by adjusting the port to use:
I usually keep port on standard port 22 and use other security means to lock this down.
Create New Admin User
We don't want user root to be able to login over SSH, as that user has no limits in privileges.
Creating a new user, who can use 'sudo', but isn't the root user, adds security:
- SSH key usually provides a first (separate) password needed, so attackers need both the SSH private key and knowledge of this password
- User then required to use their own password on top of that to run privileged commands via 'sudo'. This is missing when logged in as 'root' directly.
- We remove a vector of remote attack - root user cannot be logged into remotely
On the remote server, logged in as user root, we create a new user fideloper:
Then add user fideloper to group sudo, which allows that user to use 'sudo' commands:
Log in as user 'fideloper'
Next we want to make sure we can log into user 'fideloper'. To do so, we get our previously created id_sshex.pub (on our local computer) and paste it into the authorized_keys file of the new 'fideloper' user on the remote server.
Then, once again locally, edit the ~/.ssh/config file to adjust user from 'root' to 'fideloper':
Make it look like this:
Save that and then attempt to log into our server (again, from our local computer):
And we should get logged in as user 'fideloper'!
Disable SSH login of user root
Back on the remote server, let's edit the sshd_config file some more and lock down who can login and how further.
Disable the login of user root:
Save that and restart SSH:
Sshd Configure
Back on our local computer, try to login as root again:
This will ask for a password but tell is permission is denied, even if using the right password.
Disable password authentication
On the remote server, edit sshd_config and turn off the ability to login over SSH using password:
Edit the 'PasswordAuthentication' directive:
Save that and restart SSH:
Locally, try to login as user 'root' again and see you get permission denied:
Allow SSH login by user or group
On the remote server, edit sshd_config and explicitly set which users can SSH into the server:
Add the 'AllowUsers' directive:
Save that and restart SSH:
Locally, log in as user 'fideloper' successfully:
Back on the remote server, let's use the 'AllowGroups' directive instead:
Add the 'AllowUsers' directive:
Save that and restart SSH:
Locally, add a new Terminal tab (DON'T LOG OUT OF YOUR CURRENT SESSION) and try to login again:
You'll get denied, as none of our users are in group 'allowssh'.
On the remote server, create that group and assign it to user 'fideloper':
Sshd Default Config
Locally, try to login again and see that you can login:
In the end, I allow both 'allowssh' and 'sudo' group to login over SSH:
Sshd Config Example
As always, save that and restart SSH: