I wrote a series of blog posts a while ago about SSH authentication using cryptographic keys rather than passwords. I discussed why SSH keys provide easier authentication, how to set up an SSH key agent, and how to maintain multiple websites.
There are two areas of security to consider regarding SSH. I think of them as the math and the management.
Cryptography is a specialization within mathematics. The details are quite challenging, but the good news is that it provides numbers. We can make meaningful statements about the difficulty of an attack, and thus the security of the system.
What about the attackers we need to worry about? They aren’t crazy. They know better than to waste their time trying to guess working cryptographic keys. I have a collection of logs from a set of 12 Linux workstations. They were exposed to the Internet around the clock for a number of years. In one year’s log data I find:
SSH supports not only the older RSA public-key algorithm but also the newer ECDSA and Ed25519 public-key algorithms using elliptic curve cryptography. ECDSA keys are 521 bits long and Ed25519 keys are up to 256 bits long. As per the classic NIST publication “Recommended Elliptic Curves for Federal Government Use“, that provides strength against brute-force attack of about 256 and 128 bits, respectively. So, an attacker would have to expend 2256 and 2128 operations, respectively, to discover the corresponding private keys.
Those are enormous numbers! As a result, attacks are unlikely to happen, let alone succeed. Written in base 10, 2128 has 39 digits and 2256 has 78 digits.
And, as I described regarding SSH key agents, it is very easy to use cryptographic authentication. That’s great for the user.
But, this may represent a risk for the organization.
The risk to the organization is that SSH keys are too easy to deploy.
SSH Communications Security has published a great analysis of SSH key management risks. It explains how unmanaged SSH user keys can pose huge risks to companies and government agencies.
The system administrator culture over the past 20 years has encouraged casual self-provisioning of accounts and the corresponding key access.
They have found that large organizations sometimes have well over one million SSH keys. In some cases, over 90% of those are associated with accounts no longer in use and perhaps unmonitored (but still quite usable). Some of the time 10% or more of the keys provided root access!
That gets into another management issue. Your policy may require keeping track of which human carried out each unconstrained root access. But, remotely connecting as root makes it impractically difficult to trace every remote authentication back to some human at a keyboard.
This casually unmanaged self-provisioned situation is incompatible with formal compliance requirements. For example, the U.S. Cybersecurity Framework, the Sarbanes-Oxley Act, HIPAA, the Payment Card Industry Data Security Standard, and others. These require the careful management of who is able to access what, and that in turn requires careful management of SSH keys. Keys must be carefully provisioned, replaced, and retired.
Take a look at the NIST publication NIST IR 7996, “Security of Interactive and Automated Access Management Using Secure Shell (SSH)”. It explains the fundamentals, the risks, and the recommended practices for SSH security policies and procedures. It then describes the planning and deployment of SSH-based IAM or Identity and Access Management.
You must configure SSH servers carefully. Prevent root access and only allow certain SSH identities to authenticate in specified ways. As for how to do that, see Learning Tree’s Linux server administration course. The access control can combine packet filtering through the Netfilter modules of the operating system kernel, the SSH server configuration, and PAM or Pluggable Authentication Module rule sets. That flexibility gives you whatever combination of access control and logging you might need.
As an advanced topic, the Linux optimization and troubleshooting course goes further into detail on SELinux (or NSA Security-Enhanced Linux). This includes debugging SELinux policies and creating your own SELinux modules.