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

Passwordless login

[Smallpond]

I've just noticed a huge vulnerability in keyless entry on cars - you can open the door without a key!

** just so we don't have a story without a car analogy **

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

His name is

[LucidBeast]

Tatu Ylönen

Re:By not using SSH

[vlm]

What do you use to log in from one machine into another, telnet? Or instead of scp you ftp stuff?

Also I have several boxes where the only way I can run "X" GUI stuff (at home, my mythtv backends) is via SSH X11 forwarding.

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.

Re:Inability of server to enforce policy

[nedlohs]

Of course there isn't. The server doesn't see the passphrase and there'd be no point in trusting the client to tell you "oh yeah, there was a huge passphrase, I promise".

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:Passwords are a worse vulnerability

[vlm]

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

Hey slashdot does anyone have an implementation where the sshd config would look something like:

PubkeyAuthentication yes
PasswordAuthentication no any/any
PasswordAuthentication yes 10.0.0.0/8

And no, last time I checked openssh could not do that. Either yes or no, no src address filtering.

The closest I could come up with is running two SSH servers on different port numbers and filter at the network level which src addrs can talk to which port.

Re:Passwords are a worse vulnerability

[Qzukk]

And no, last time I checked openssh could not do that

Last I checked, PasswordAuthentication is allowed inside a Match block, so

PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8
        PasswordAuthentication yes

Re:Passwords are a worse vulnerability

[shaiay]

use the Match config file directive:

PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8
PasswordAuthentication yes

Re:Passwords are a worse vulnerability

[Maow]

(years ago) I used to get blasted at home from China IP addrs trying various root passwords. Flooding my logs with failures. Since then I only allow key auth from the untrustable internet. I'd never allow password auth over the internet. Copying a key is not a big deal. Or logging into another machine that I know has a key, etc.

On the LAN, if some clown gets infected and port scanning / password scanning, I can literally walk over and physically take care of it.

This may not be of use to you anymore, but I'll toss it out there: fail2ban.

I use it to ban IPs attempting ssh-as-root on first attempt, ssh login password failures on 3rd attempt. Uses iptables to block the malicious addresses. Works like a charm.

Also has "jails" for Apache-based log failures, such as attempts to access PHPMyAdmin (what ever it's called), which is worthwhile to run just for that, and a host of others.

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.

Re:who is doing this?

[Anonymous Coward]

I always run my backup scripts in chroot environments. I've also found that, as a bonus, they complete many orders of magnitude faster and use significantly less space. Huge wins all around.

Re:who is doing this?

[gmack]

It is not a matter of password protecting ssh keys, it is a matter of deleting obsolete keys from ~/.ssh/authorized_keys when they aren't used anymore. When someone quits or gets fired someone should be going through everything they have access to and removing the keys. They are remarkably easy to forget where they were put as well.

After running my head into this problem one too many times I ended up creating a management system that rebuilds every copy of authorized_keys on each server.

Re:who is doing this?

[nabsltd]

I think you are trying to be funny and failed (also I think you are mixing up chroot and /dev/null)

If you chroot, you can't see any files if the aren't in the chroot directory or below. So, if you want to back up /etc, your chroot better include /etc (either as the root or as a subdirectory).

This is why the OP said the backup finished faster...because after the chroot, none of the files that needed to be backed up were visible.