Linux: Securing OpenSSH


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 restart of OpenSSH after the modifications have been made.  In general, a restart should not reset any existing connections; as always, though, anyone doing remote maintenance should have a contigency plan in place.

In most Linux distributions, OpenSSH can be restarted via either the openssh or ssh service.  The following commands must be run as root, or a user with root access; 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.)

# /etc/init.d/openssh restart

or

# /etc/init.d/ssh restart

In a sudo-based distribution, the command would look like:

$ sudo /etc/init.d/ssh restart
 

sshd_config

Most of OpenSSH'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; it must be edited with root access.

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 restarted 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

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.

OpenSSH must be restarted for this to take effect.
 

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.

7913
9/24/2019 7:17:46 AM