There are a few adjustments that can and should be made to the default SSHD configuration to increase security. Traditionally, this has been especially true of RedHat-based systems, which included weak default configurations. The main point of interest is the /etc/ssh/sshd_config file. To cause changes made in this file to take effect, SSHD will need to be restarted or sent a sighup. This can be achieved on Linux systems which use SysV init scripts like:
# /etc/init.d/ssh restart
or:
# /etc/init.d/sshd restart
On FreeBSD systems there is often an init script located in /etc/rc.d :
# /etc/rc.d/ssh restart
In any case, you can just send the sshd process a sighup:
# kill -s HUP `ps aux | grep sshd | awk ‘{ print $2 }’`
As far as the settings concerning security, the first to look at is the port which SSHD listens on. There is a lot of debate on this matter, but often it is recommended to change the default port away from 22 to a random unprivileged port, the higher the better. While a simple port scan will still find SSHD running on a server, moving the default port will field many automated probes and brute-force attempts. To change this, find the following line:
Port 22
And simply change the 22 as previously mentioned. You can limit the address which sshd listens on with the “ListenAddress” directive. Typically this is commented out by default; if you have several IP’s available to you, you could tell it to only listen on one which is being used for nothing else, or you could set it to only listen on an IPv6 address:
ListenAddress xx.xx.xx.xx
Next is the “Protocol” directive, which tells SSHD what protocol to allow. Protocol 1 is deprecated and known for its many security issues, so this should be limited to protocol 2:
Protocol 2
The “HostKey” settings typically include both RSA and DSA keys for protocol 2, and may also include an RSA key for protocol 1. DSA keys are currently considered more secure, so by removing the protocol 2 RSA setting you force the daemon to use the DSA key. The “PermitRootLogin” directive is another which should be set to “no”. This means you will have to ssh in as a regular use, then use the “su -” command to become root. It also means no one else can ssh into your server as root:
PermitRootLogin no
It is also highly desirable to setup key-based authentication. With PKI, a three-way challenge-response handshake is used, and if you also specify a passphrase during key creation, this complicates matters even more. Full details on setting this up can be found in the ssh-keygen manpage:
$ man ssh-keygen
Of course, if you’re connecting from a windows machine, the setup may be rather more complex. You’ll want to consult the documentation provided with the SSH client which you’re using to connect. Another setting of interest is “PasswordAuthentication”. With PKI setup and this set to “yes”, logging in via the standard password is still permitted for those who do not have a key infrastructure in place. Setting this to “no” forces PKI. While PKI is not the only option for replacing plaintext passwords, it is a good, strong method. There is also Kerberos, GSAPI, and PAM can also be added as another mechanism. For information, consult the sshd_config manpage:
$ man sshd_config