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
administrators have turned off password authentication entirely. That
means that users must have keys installed on hosts they need to access,
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
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
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:
Using password-protected keys, the decryption of the private key
is done on client side (to protect the confidentiality of the key), and
there is nothing in the SSH protocol which could stop the behavior of
accepting "less secure keys because they were stored in clear".
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
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:
If you're worried that your users might leave an unprotected key lying
around, you should *also* be worried that those same users might send
their password via e-mail (even if it's just "to themselves as a
reminder"), or write it in a cleartext file on their computer, reuse it
for their amazon account, for their blog, etc.
At some level, you have to trust your users if they're going to use your
system. And have good backups, easy recovery, and regular user
education about good practices, of course ;)
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.
to post comments)