Security [LWN.net]

SSH: passwords or keys?

By Jake Edge
January 13, 2010

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:

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 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:

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.

Comments (60 posted)

Brief items

BerliOS compromised

The BerliOS repository site has been compromised; indeed, it appears it has been compromised since 2005. What little information is available can be found from this (German) Heise article (Google translation) and a screen shot from the defaced site. According to the BerliOS system admin (a certain Jörg Schilling), no data has been tampered with, but those who have worked with or gotten code from BerliOS might want to be careful regardless.

Update: the Heise article is now available in English.

Comments (19 posted)

Google: a new approach to China

It may be a little off the LWN topic, but Google's a new approach to China is worth a read for anybody who hasn't yet seen it. It's a reminder of how important security practices are and what the risks of storing important data in "the cloud" can be. "Third, as part of this investigation but independent of the attack on Google, we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties."

Comments (38 posted)

New vulnerabilities

DevIL: buffer overflow

Package(s):

DevIL

CVE #(s):

CVE-2009-3994

Created:

January 13, 2010

Updated:

January 13, 2010

Description:

The DevIL image processing library suffers from a buffer overflow vulnerability exploitable via a specially-crafted image file.

Alerts:

Fedora	FEDORA-2009-13255	2009-12-16
Fedora	FEDORA-2009-13219	2009-12-16

Security

SSH: passwords or keys?

BerliOS compromised

Google: a new approach to China

DevIL: buffer overflow

firefox: multiple vulnerabilities

firefox: denial of service

gif2png: buffer overflows

horde3: cross-site scripting vulnerability

horde3: cross-site scripting vulnerability

Kerberos: possible remote exploit

kernel: denial of service

kernel: denial of service

kernel: denial of service

kernel: denial of service

kernel: multiple vulnerabilities

openttd: denial of services

pdns-recursor: multiple vulnerabilities

phpldapadmin: remote file inclusion

pidgin: directory traversal

sendmail: several vulnerabilities

sssd: authentication bypass

trac: multiple vulnerabilities

transmission: directory traversal