SSH: passwords or keys?

A recent discussion on the OpenSSH developers mailing list (openssh-unix-dev) debated the relative merits of passwords versus keys as ssh authentication methods. While password authentication has fallen out of favor over the last few years, there are still situations where it makes more sense than key-based authentication. As with many security decisions, the right choice is largely dependent on the threat model one is defending against.

Through no fault of its own, ssh is probably one of the most used (or abused) mechanisms for system compromise. Repeated brute force password-guessing attacks are a common "script kiddie" activity, which is why many administrators have turned off password authentication entirely. That means that users must have keys installed on hosts they need to access, leaving open another avenue of attack: the corresponding private keys.

When sshd is configured to disallow password authentication (via the PasswordAuthentication no directive in sshd_config), the server will no longer allow the traditional username/password pair to be used to authenticate a user. Instead, the user must generate a public/private key pair on each host that is to be used to access the sshd host (or one pair that gets shared among various client hosts—generally a bad practice). The public key gets installed in the user's authorized_keys file on the server and authentication is handled directly between the ssh client and server.

But what protects the private key? Depending on the user, and their level of security consciousness, protection could range from directory and file permissions on the private key file to a password that encrypts the private key. For password-protected keys, that means that the user must enter the password to decrypt the private key before the ssh client can use it to authenticate with the server. Since many users like key-based authentication because it doesn't require passwords, this extra level of key security can be annoying—and often gets omitted. That leaves private keys potentially accessible on the client system.

Davi Diaz wanted to know how to detect password-less keys on the server side so that authentications from those clients could be rejected. But, as Aris Adamantiadis and others pointed out, there is no way for the ssh server to know:

While password authentication has its downsides, there are some advantages to it as Mark Janssen noted: "while keys are better [than] passwords, it's impossible to enforce passphrase quality on keys, while it is possible to enforce some quality on passwords." Passwords can also be aged, so that they must be changed with some frequency. Because account passwords are under the control of the server administrator, unlike most private key passwords, an administrator can enforce strict requirements on them.

But, unlike passwords, private keys generally aren't used in multiple places, nor are they transmitted anywhere. It is a common, if insecure, practice for humans to use the same password on their LWN account that they do to log in with ssh to some other system. So, once a password is cracked or captured, it can often be used to gain access elsewhere.

There are also ways that compromising a single private key can lead to the compromise of multiple systems, however. If a password-less private key can be accessed—via the compromise of a client system or the theft of a laptop for example—an attacker can access any systems that have authorized that key. A single compromised private key will often allow an attacker access to multiple systems, either directly using the compromised key or by hopping to new systems that have their own password-less private keys. One particularly ugly scenario is for root to have authorized keys that allow a regular user on one system to automatically authenticate as root on the other. That is one good reason to disallow all root logins via ssh (PermitRootLogin no in sshd_config).

So, it would seem that disallowing password authentication for ssh and requiring users to password protect their private keys would go a long way towards eliminating compromises via ssh. There aren't any technological means to force passwords on private keys, but an administrator must either trust their users or disable their access. As Daniel Kahn Gillmor said:

On the other hand, requiring both keys and passwords would be even more secure. If the key was also password-protected—with a different password of course—that would make it stronger still. But the usual security/convenience tradeoff applies. That much protection will certainly annoy users, so it may only be necessary for the most sensitive systems.

There are many things that must be considered when making security decisions: the sensitivity of the data, the trustworthiness of the users, the threats being defended against, and so on. One of the things that makes security so difficult is that there is no "one size fits all" solution, each situation is different. The various authentication choices for ssh, and their relative strengths and weaknesses, just bear that out.