Lax SSH Key Management A "Big Problem"

cstacy writes "Tatu Yionen, inventor of SSH, says he feels 'a moral responsibility' to come out of retirement and warn that a 'little-noticed problem' could jeopardize the security of much of the world's confidential data. He is referring to the management (or lack thereof) of SSH keys (i.e. 'authorized_keys') files. He suggests that most organizations simply allow the SSH key files to be created, copied, accumulated, and abandoned, all over their network, making easy pickings for intruders to gain access. Do you think this is a widespread problem? How does your company manage SSH keys?" cstacy's summary here is accurate, but as charlesTheLurker notes, the article is a bit over the top: "The Washington Times claims that there's a huge vulnerability in ssh. It turns out that some reporter there has discovered that you can do passwordless login with the software, and has spun this into a story of a dangerous vulnerability. Sigh."

Comments

Your keys, my keys

[kthreadd]

I've worked at a place where someone thought it was a great idea to mass-add a specific entry everyones authorized_keys, "because then $x would just work". No need to tell everyone of course.

It's not enoguh that you know how to manage your keys. The rest of the organization has to know what's OK and not.

Re:who is doing this?

[sribe]

Who exactly is it that isn't password protecting their ssh keys?

Anyone who needs services to launch without manual intervention--which is a whole lot of services and a whole lot of people...

Inability of server to enforce policy

[linuxtelephony]

The biggest issue with SSH is the inability of the server to enforce policy on the client keys. If I'm wrong, I'd love to be corrected and learn what I've been overlooking.

As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase. Short of over-the-shoulder random audits of users using their keys, there's no way to enforce a policy that sets minimum standards for pass phrases on SSH keys.

To my way of thinking that is one of the bigger areas of risk with and drawbacks of the use of SSH.

Re:Inability of server to enforce policy

[vlm]

Its a mess. In more detail.

The pass phrase never leaves the client, right, so you'd have to magically protect against trojaned client that lies and pinky swears that it really did check.

Or send the passphrase cleartext to the server for the server to test it. That would be bad. Of course if you had a trustable connection between, then you could safely transfer the passphrase to the server for testing, but then you'd already trust the link so it would be pointless.

The solution is after you set up the trusted link you send the passphrase over the link and have the server verify the phrase and dump the connection if it fails.

There's probably some horrible failure mode where if a server is owned then you're really screwed because now it has your passphrase which is probably your gmail password and xbox password and who knows what else.

Kerberos does it (somewhat) better.

Passwords are a worse vulnerability

[betterunixthanunix]

I see brute force attacks on passwords all the time; you do not see that with keys. Yes, if you are dealing with an adversary who is organized, well-funded, and specifically attacking you, you should be taking extra precautions with keys (and with many other things), but for most SSH use-cases the adversary is just trying to find the least secure system anywhere on the net, and does not care who owns it.

So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.

Re:who is doing this?

[kthreadd]

Then I would create a separate key for that service and restrict what it was allowed to do on remote end.