Lax SSH Key Management A "Big Problem"

← Back to Stories (view on slashdot.org)

Lax SSH Key Management A "Big Problem"

Posted by Unknown on Wednesday December 26, 2012 @04:18AM from the we're-all-doomed dept.

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

31 of 212 comments (clear)

Min score:

Reason:

Sort:

Passwordless login by Smallpond · 2012-12-26 04:20 · Score: 5, Funny

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 **
1. Re:Passwordless login by NatasRevol · 2012-12-26 05:14 · Score: 2
  
  Or a librarian.
  Or even Nicholas Cage.
  
  --
  There are two types of people in the world: Those who crave closure
2. Re:Passwordless login by davester666 · 2012-12-26 07:43 · Score: 2
  
  Yes, that huge gaping hole where the roof normally is...
  
  --
  Sleep your way to a whiter smile...date a dentist!
who is doing this? by datapharmer · 2012-12-26 04:22 · Score: 2

Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.

--
Get a web developer
1. Re:who is doing this? by sribe · 2012-12-26 04:31 · Score: 5, Insightful
  
  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...
2. Re:who is doing this? by kthreadd · 2012-12-26 04:39 · Score: 5, Insightful
  
  Then I would create a separate key for that service and restrict what it was allowed to do on remote end.
3. Re:who is doing this? by h4rr4r · 2012-12-26 04:53 · Score: 2
  
  Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.
4. Re:who is doing this? by vlm · 2012-12-26 05:02 · Score: 2
  
  We just put the password in another file, and use a script to handle it.
  Naah just put the password on the command line. What could possibly go wrong?
  (Note, just kidding)
  At one point I had at work an implementation looking a lot like the Debian development anon-ftp system... Sure, upload whatever you want, but if its more than 5 minutes old and has no valid GPG signature, then it gets wiped. On the other hand if its got a valid GPG sig, trust it and run it. If you're going to put an anon ftp server on the internet you need to partition upload and download so as not to become a warez site. I suppose if there was a buffer overflow in GPG (or the ftp server, or my lame little wrapper script) I would have been pretty well screwed. Also put some sensible limits on it for ddos reduction.
  "Run any script you see, as long as its got a valid GPG sig..." is a pretty simple wrapper. Authenticate the code, not the transfer, more or less. Essentially, a crude DRM system... I wish this design/pattern were more "mainstream".
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
5. Re:who is doing this? by sribe · 2012-12-26 05:28 · Score: 2
  
  Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.
  Yep. And more directly related to the article--not being a dipshit idiot about the key files ;-)
6. Re:who is doing this? by Anonymous Coward · 2012-12-26 06:04 · Score: 5, Funny
  
  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.
7. Re:who is doing this? by gmack · 2012-12-26 06:36 · Score: 4, Informative
  
  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.
8. Re:who is doing this? by nabsltd · 2012-12-26 08:08 · Score: 3, Informative
  
  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.
Your keys, my keys by kthreadd · 2012-12-26 04:29 · Score: 4, Insightful

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.
1. Re:Your keys, my keys by vlm · 2012-12-26 04:38 · Score: 2
  
  Would have been a lot funnier if they did
  cat somekey > ~/.ssh/authorized_keys
  rather than
  cat somekey >> ~/.ssh/authorized_keys
  I suppose that is one way to "solve" the problem.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
His name is by LucidBeast · 2012-12-26 04:31 · Score: 4, Informative

Tatu Ylönen
Re:By not using SSH by vlm · 2012-12-26 04:35 · Score: 3

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.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Inability of server to enforce policy by linuxtelephony · 2012-12-26 04:36 · Score: 4, Insightful

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.

--
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
1. Re:Inability of server to enforce policy by h4rr4r · 2012-12-26 04:49 · Score: 2
  
  If you are that worried about it you could disable the use of ssh keys. No one is going to be guessing the keys anyway, but it is a concern if someone copied one.
2. Re:Inability of server to enforce policy by vlm · 2012-12-26 04:52 · Score: 4, Insightful
  
  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.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
3. Re:Inability of server to enforce policy by icebraining · 2012-12-26 04:53 · Score: 2
  
  That's because the server has no way of knowing anything about the passphrase unless the client tells it, and no way of knowing if the client is telling the truth, so it would be foolish to include such verification.
  
  --
  Dilbert RSS feed
4. Re:Inability of server to enforce policy by betterunixthanunix · 2012-12-26 05:04 · Score: 2
  
  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
  There is, however, a way for the server to accept only particular client keys -- say, keys that are known to have been generated on a smart card. SSH can be configured to look for authorized keys somewhere that users cannot write to (a basic centralized keystore), and there is some amount of support for a PKI. You cannot force users to have good passphrases, but you can force them to use smartcards (which is probably better than a passphrase anyway).
  
  --
  Palm trees and 8
5. Re:Inability of server to enforce policy by DamnStupidElf · 2012-12-26 05:19 · Score: 2
  
  This is basically the heart of the issue. Allowing users to add whatever keys they want (their uncle? Their best "friend" in Russia?) to their own user accounts circumvents the traditional authentication/authorization methods. When employees leave, occasionally their accounts stick around while things get cleaned up (or if they were especially bad and running production jobs out of their home account, they just stick around forever) their /etc/secrets entry gets a * for a password hash immediately but it's not obvious to check their personal .ssh directory and clean up authorized_keys. Especially if that annoying production job happens to use ssh in a non-trivial way. Single sign-on systems are a possible solution. OpenSSH supports Kerberos integration and that may be the way to go for big *nix enterprises.
6. Re:Inability of server to enforce policy by nedlohs · 2012-12-26 07:01 · Score: 3, Informative
  
  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".
7. Re:Inability of server to enforce policy by GreyWolf3000 · 2012-12-26 07:21 · Score: 2
  
  When the smartcard is given a public/private key pair, it registers the public key with a basic centralized keystore. Then the ssh server starts refusing key authentication with any client not trying to authenticate against one of the public keys generated by the smartcard setup process.
  
  --
  Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Passwords are a worse vulnerability by betterunixthanunix · 2012-12-26 04:39 · Score: 5, Insightful

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.

--
Palm trees and 8
1. Re:Passwords are a worse vulnerability by vlm · 2012-12-26 04:45 · Score: 3, Interesting
  
  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.
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
2. Re:Passwords are a worse vulnerability by Qzukk · 2012-12-26 05:07 · Score: 4, Informative
  
  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
  
  --
  If I have been able to see further than others, it is because I bought a pair of binoculars.
3. Re:Passwords are a worse vulnerability by ArsonSmith · 2012-12-26 05:11 · Score: 2
  
  xinetd can. we launch a separate sshd with separate config file from xinetd with response from only certain ip addresses.
  
  --
  Paying taxes to buy civilization is like paying a hooker to buy love.
4. Re:Passwords are a worse vulnerability by shaiay · 2012-12-26 05:27 · Score: 4, Informative
  
  use the Match config file directive:
  PubkeyAuthentication yes
  PasswordAuthentication no
  Match Address 10.0.0.0/8
  PasswordAuthentication yes
5. Re:Passwords are a worse vulnerability by Maow · 2012-12-26 06:50 · Score: 3, Interesting
  
  (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.
It's not hard by geekboybt · 2012-12-26 05:35 · Score: 2

Managing SSH keys for known service accounts is easy with configuration management tools like Puppet, Chef, or Salt.