OpenSSH is the most common method used for remotely accessing Linux, BSD, and UNIX machines. When properly configured, it can provide a very secure environment; however, not all installations of OpenSSH are created equally, and taking the time to increase the security of an install can help to keep a machine from getting compromised.
Restarting OpenSSH
Most of these changes require a reload of OpenSSH after the modifications have been made. In general, a reload should not reset any existing connections.
In most Linux distributions, OpenSSH can be restarted via either the openssh or sshd service. The following commands must be ran as a user with elevated privledges (root). If running a sudo-based distribution, you can run them as an administrative user by adding sudo to the front of the command. (The # or $ at the front of the line represents the prompt, and should not be typed.)
Most modern Linux operating systems utilize systemd to manage services. To reload a sshd config after changes have been made the following command can be used:
# systemctl reload sshd
or
# systemctl reload openssh
In a sudo-based distribution, the command would look like:
$ sudo systemctl reload sshd
sshd_config
The OpenSSH server's behavior is controlled via the server's configuration file, almost always named sshd_config. This file usually lives in either /etc/openssh or /etc/ssh. The file must be edited with elevated privledges.
The file consists of a series of lines that contain a keyword and a value. Lines whose first non-whitespace character is a pound sign are comments and do not affect the behavior of the server.
PermitRootLogin
By default, most OpenSSH configurations allow remote root access to the server. This is generally unnecessary, and a large potential security problem. This can be disabled via the PermitRootLogin keyword:
PermitRootLogin no
OpenSSH must be reloaded for this change to take effect.
Protocol
There are two different versions of the OpenSSH protocol. The older version 1 has known security problems and should not be used to encrypt communications any more. By default, most modern clients will only use version 2 of the protocol; this can be ensured by the use of the Protocol keyword:
Protocol 2
This is different from the more-typical Protocol 1,2 which allows both version 1 and version 2. OpenSSH must be restarted for this change to take effect.
AllowUsers, AllowGroups
If there are a limited number of accounts that need remote access via SSH, these accounts can be explicitly listed via the AllowUsers keyword. Any accounts not listed here will not be able to log onto the machine with SSH, even if they have a local account. An example:
AllowUsers phil jsmith root@127.0.0.1
Note the root@127.0.0.1 line. Any account's remote access can be further narrowed by stating what addresses they can use to connect; root@127.0.0.1 states that root can only connect via SSH if they are coming from 127.0.0.1 (the machine itself). Note that this does not override the PermitRootLogin keyword. This is useful if you still need to be able to SSH into the root account locally (for graphical applications, for example) but do not need remote access to that account.
The following command can be used to only allow particular groups to connect via SSH
AllowGroups users mikesfriends
OpenSSH must be restarted for this to take effect.
PubkeyAuthentication
For best security, it is preferred for all users to connect using public-private key pairs. These can be easily created using the following command:
# ssh-keygen -t rsa
and subsuquently added to the machine they wish to connect to via the ssh-copy-id command:
# ssh-copy-id mike@mikethetiger.lsu.edu
Once the key is added, your machine will automatically attempt to use this key to connect to other servers as well. You can use the same command above to add your public key to other servers.
Once a user is exclusively using public/private key pairs, one can use the Match command in sshd_config to deny authenticating via password to further secure an account:
Match User mike
PasswordAuthentication no
Further Actions
By using the firewall software that comes with most modern Linux distributions, iptables, you can further narrow the level of access that outside users have to a machine via SSH. While an exploration of iptables configuration is outside the scope of this article, there are many sources of information on the Internet to help you configure them properly to limit access.
Sample sshd_config
Below is a sample configuration file for sshd_config. There are extra commands used in the config which were not mentioned previously. Additional information can be found in the documentation for sshd on what those commands do:
# Connection
Port 22
Protocol 2
UseDNS no
Compression no
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
# Logging
SyslogFacility AUTHPRIV
LogLevel INFO
# MOTD
PrintMotd no # pam does that
banner /etc/ssh/banner
# Allowed users
AllowGroups root users
PermitRootLogin no
# Authentication:
PubkeyAuthentication yes
PermitEmptyPasswords no
UsePAM yes
UsePrivilegeSeparation sandbox
ChallengeResponseAuthentication yes
LoginGraceTime 60
MaxAuthTries 4
MaxSessions 100
AuthorizedKeysFile .ssh/authorized_keys
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
# override default of no subsystems
Subsystem sftp-server /usr/lib/ssh/sftp-server
Subsystem sftp internal-sftp
# Deny root password authentication
PasswordAuthentication no
Match User *,!root
PasswordAuthentication yes