root ssh access trick

Free Software Daily had an interesting post the other day about securing SSH services (that post points to a Tux Training article). This particular tutorial included a configuration item I hadn't seen before. It's a configuration value for the PermitRootLogin field.

If I'm running an SSH service which is visible to the Internet (or even a large intranet), I tend to disable PermitRootLogin (PermitRootLogin no), because the script kiddies can be reasonably sure that an SSH service will have a user called root, and if they try hard enough, they might get lucky with the password.

(I'm also a big fan of the AllowUsers option, which allows you to provide a list of users allowed to log in via ssh. If a valid user not on that list tries to log on, ssh acts as though the user has provided the wrong password.)

The new (new to me, anyway) trick in this tutorial is setting PermitRootLogin without-password. This allows root to log in with a key, but not with a password. This is a really good compromise if you have a server where you need root to be able to log in over ssh. Backups over rsync are a good example of this: to preserve file ownership and permissions, it's sometimes necessary to have rsync run as root.

ssh security features

ssh offers ssh keys as a nice alternative to password authentication, and putty is a pretty cool ssh client for Windows. There's a good tutorial on howtoforge which discusses many of the features of the putty suite including key generation (puttygen) and putty's ssh-agent (pagent).

And as the above article mentions, the PasswordAuthentication option in sshd_config can be cleared to force the use of ssh keys (password authentication will be disabled).

AllowUsers is another good sshd_config option. It can be used to provide a list of users who can connect via ssh. Any user not in this list can't connect by ssh. It's good for defeating ssh scans which try a few passwords against common account names (like root, guest, etc.). Another trick that might help dodge ssh scans is to run ssh on a port other than 22. The ListenAddress sshd_config option can be used to run ssh on some other (non-standard) port.

A nice trick for your ~/.ssh/authorized_keys file is to specify source hosts from which you can connect using certain keys. If you have the following in your authorized_keys file, then the key in question can only be used for connections from the hosts listed in the from list:

from="this_host,that_host" ssh-dss ...key data... USER@HOST

(This is discussed in the 'AUTHORIZED_KEYS FILE FORMAT' section of the sshd man page.)

Finally, the denyhosts project claims to be able to do dynamic edit to the tcpwrappers files (/etc/hosts.deny) when dictionary attacks are detected. It would probably be really useful for a server with lots of ssh users that need to log in from anywhere/everywhere.