SSH is a fantastic way for Linux or UNIX administrators to manage their servers securely from remote locations. It's also the single most attacked service on a UNIX-like system. As a result, some common-sense hardening steps are necessary to keep your hosts secure. For this reason, I will cover some of the most simple to implement steps towards perfect SSH security in this brief article.

1. Don't allow the old SSHv1 protocol. It is enabled by default on some distributions for compatibility with older UNIX clients. Since SSHv1 is totally obsolete and has a bad security track record, stick with SSHv2 only.

---

Protocol     2

---

2. Forbid direct root logins. Root is the most powerful and therefore the most sought-after account in a target system. For this reason, there's no compelling reason for the root user to be able to login through SSH directly. Forbid this practice in your sshd_conf, then login as an unprivileged user and su to root instead:

---

PermitRootLogin     no

---

3. If possible, avoid running SSHD on the standard port (22). Nearly any compromised hosts out there will be scanning for port 22 explicitly, so the simple act of running your SSH daemon on an alternate port, for instance 22222, will eliminate most of the random scripted attacks your system will face.

---

Port     22222

---

4. Isolate the user's SSH process from the system. If an exploit is found in the OpenSSH daemon, an uncommon yet possible scenario, it may be possible to get system level access since SSHD must run as root. This can be countered by utilizing a feature of the OpenSSH server which has been built-in since around version 3.2: privilege separation. This launches the initial listener service as a privileged user, but once an unprivileged user connects, the process is forked with the permissions of the connecting user. This has already prevented potential exploits to OpenSSH in the past, so it should always be utilized whenever possible. You can enable privilege seperation by adding or uncommenting the following line to your sshd_conf:

   ---

   UsePrivilegeSeparation      yes

   ---

5. Don't allow just any accounts on the system to login with SSH. Limiting which users can login through SSH will greatly limit the possible vectors of attack, and will make auditing logins much simpler. My suggestion is to create a system group called something like sshlogin, then add only those few users who will need to login via SSH. Finally, specify this group with the AllowGroups option in your sshd_conf. This will forbid anybody who is not a member of that group from logging in through SSH.

---

AllowGroups     sshlogin

---

6. Enforce strong passwords for those who do need to login. If an attacker does have a specific target user account, or if the user has a relatively common username, it is a good candidate for brute-force attack. The best scenario is to always implement best-practice password policies, and furthermore enforce those policies at the system level. A good way to do this is with PAM, which is too deep a topic to do justice here. If you wish to learn more about PAM, you can about it in depth here.
   
7. Brute-force attacks shouldn't go unanswered. If you are especially conservative about security, an SSH-hardening script is an excellent option. With such a scenario, any host who tries too many times (based upon your stipulations) to login via SSH will be blacklisted, and no further attempts will be allowed from that IP. This will effectively prevent attackers from trying to crack passwords on your SSH server via brute force methods in order to gain access. You might consider Fail2ban or CSF for this task. Not only can they react to attacks against SSH, but also threats to web, FTP, and various other vectors.
   
8. If possible, consider RSA Authentication instead of interactive password logins. If you're in a scenario where it's prudent to use public keys for authentication rather than password-based logins, you might consider it. Crpytographically, RSA key authentication is more secure than even very strong passwords, and can make the connection phase of SSH much more VPN-like in nature. There are advantages and disadvantes to this method however. The primary advantages are convenience, added cryptographic durability, and the ability to prevent brute-force attacks to an extremely high degree. Note, however, that this form of authentication is only truly effective as a brute-force deterrent if all other forms of interactive authentication are disabled.