Slashdot Mirror
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."
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 **
We manage this problem by having the office workplace be an offline, local office network. There isn't any connecting remotely through VPNs/SSH, if you're doing work, you come to work to do it.
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
Unmanaged keys are most certainly a pretty serious security vulnerability, and I agree - in my experience it is endemic.
Key management - signing, validation, revocation - doesn't happen for free. Everything worthwhile requires effort.
..don't panic
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.
Tatu Ylönen
In my opinion, this is the interest of the new authorizedkeyscommand. A sample usage is available at http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/
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
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
Post your 'authorized_keys' file and fqdn here to find out.
You, sir, are living in the 20th century.
Quite dismayed that the orginal article doesn't start to go down a bit further looking at the commercial SSH solutions with various levels of key management; SSH inc, Dell(Quest/Vintella), Venafi, CA, FoxT and others. They've been doing business for decades, using "improved SSH key management" as one of their key messages, and their target markets are corporates with strong brands, energy companies, financial services organisations and goverments. Would like to see a new survey slicing up the Open SSH and Commercial SSH footprints.
It's Tatu Ylonen.
Sure lax anything is a problem. If you are placing authorized_keys files that are wide open, to a wide open SSH that just sits around for years, ya I see a problem. If done right there are restrictions that can be added in an authorized_keys file
from="IP.address" - set a key to only be able to be accessed by a certain ip
command="some command" - only allow a certain command to be run.
I also feel that ssh should not be wide open if possible. IP restricted by either a firewall, tcp wrappers or AllowUsers in sshd_config.
So I read the TFA. And while the Times article is a bit on the sensational side, so is Slashdot's characterization. I saw nothing to indicate 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"... I did see the reporter speaking to an expert about an obscure, but real, problem and reporting on it. I suspect because that expert raised the issue himself.
All news organizations tend to sensationalize, not just those with which the majority of Slashdot editors and readers have editorial disagreements with, because it sells papers (or airtime or page views). If the Times is to be faulted, it's for characterizing this problem as a 'glitch' rather than a management practices problem in the headline.
-1? wtf
#1 "Good Enough" Is "Good Enough": /etc/ssh/keys/%u'
'AuthorizedKeysFile
#2 "Best Practice": /dev/null'
Compile openssh with LPK patch (LDAP Public Key) and use 'AuthorizedKeysFile
Second way is centralized and much more secure.
SSH keys for the root account are managed by cfengine/chef/puppet/etc and those are held only by users. Someone quits, all servers have updated authorized_keys in a few minutes. If someone with non-root permission quits then it's just one server that needs to have a user account locked out appropriately.
Servers can ssh into each other for special purposes (eg: remote backups), but not as root. They have to go into an account created just for them where the user's "shell" will do the work on its behalf using sudo where necessary. Sure it's a bit more annoying but it's the Right Way.
And don't forget about a possible authorized_keys2 file! If you're doing custom automation of SSH key management, treat authorized_keys2 the same way you do authorized_keys.
TODO: Key rotation policy for users :-(
This article is pretty much about me.
Managing SSH keys for known service accounts is easy with configuration management tools like Puppet, Chef, or Salt.
instead of using easily-guessable passwords :-(
It's not perfect, but - if you restrict where it (ostensibly) can connect from, and you restrict it to a specific command, I wouldn't exactly consider it low-hanging fruit.
#DeleteChrome
I got to the end and was thinking all my SSH keys require a password as well. Then I saw the tidbit of some dumbass had one that was passwordless, read epic fail.
I am Bennett Haselton! I am Bennett Haselton!
His name is Tatu Ylönen.
His name is Tatu Ylönen.
His name is Tatu Ylönen...
Escher was the first MC and Giger invented the HR department.
Monkeysphere
Is he going to run around yelling, "The plane, boss the plane!"
That would be a good reason to come out of retirement.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
In my opinion, this is the interest of the new authorizedkeyscommand. A sample usage is available at http://www.sysadmin.org.au/index.php/2012/12/authorizedkeyscommand/
Nice! AuthorizedKeysCommand (introduced 2012/10/31) can do exactly what we need: Set up a script that (securely) logs key usage and e.g. deny any key that is older than 366 days (by first use or else filesystem timestamp) and hasn't been used in 90 days or for any user whose last login (regardless of which key) was over 60 days ago, with a list of exceptions (by key, not user).
That's still messier than something that can go right into the authorized_keys file as a parameter, but it would do the trick handily.
Use my userscript to add story images to Slashdot. There's no going back.
It would be nice if OpenSSH could query an LDAP server for the sshPublicKey field directly. There's a patch that does it, but as far as I know it's not integrated into the main ssh code base that ships with general Linux distributions. Supporting that and then having people use the SSHFP record with secure DNS would be nice additions to SSH best practices.
The SSH design of how keys are actually handled is part of the problem. This design makes things harder for key management. The first is that the ssh daemon wants to only look at one file. It should provide for a way to keep the files separate so it is not necessary to rebuild the authorized_keys file. Have a directory where keys can be stored with multiple keys per file. Provide an option to allow the user to configure which key files are active (choose whether not executable or not world readable is the flag).
now we need to go OSS in diesel cars
Set up a one time password server require otp authentication over PAM so that even if the key is set up without a password you still need to enter the OTP. Added bonus of not having to worry about somebody sniffing your passphrase when you log in from that shady internet cafe while in thailand trying to pick up ladyboys.
I mean seriously, you guys are all a bunch of fucking amateurs!
Mahalo gaybos
my company deletes them every 30 days
I really wish SSH could be made to have some set of CAs (*not* 'the' list of CAs) and do x509 based PKI. Even though the common use (browser curated set of global CAs all with equal power) has serious issues, x509 is a decent strategy for PKI.
For host keys, DNSSEC SSHFP records being more common could help.
In terms of loosely maintained/abandoned user keys, people should probably advocate stronger for things like key agents and agent forwarding. Nearly all the convenience of passwordless usage with significantly reduced risk.
Stop authenticating users via keys directly to a server. Use Kerberos v5. This centralizes the authentication to one or a set of servers. You then don't need to clean up key mess everywhere. Once you're running Kerberos you can choose the method of authentication to the central server. You can use password, public key (but only one in this case), OPIE (One-time Passwords In Everything), Google authenticator, RSA securid, biometrics, SRP (Secure Remote Password), or any combination of these to make things 2, 3, 4 or X factor authentication. The sky is the limit, and there's no crazy mess to have to follow up with.
When you need to have things automated, and you must use key authentication, then make sure that the area the key authenticates to is well sandboxed with something like a FreeBSD jail with access to nothing but the resources needed for the remote function to be performed.
This is all using standard practices that are over a decade old (and clearly spelled out in the FreeBSD Handbook among many other places).
Posting anon since maybe this is confidential but well
OP suggests that "most organizations simply allow the SSH key files to be created, copied, accumulated, and abandoned"
At $WORK, every server has a client cert (http kind) and regularly runs a script that connects to a central server (auth with http client and server cert) to download list of authorized UNIX user/ssh key combos (by user, by department). If download is OK, it overwrites $USER/.ssh/authorized_keys. Central server is tied in to corporate directory so that if somebody gets fired (or gets moved to a department without access to that server) their key disappears from the server(s) automatically. Of course, there is a safeguard so that we can still log in if HR malfunctions and fires everybody :)
We could probably set up some central auth server to be consulted in real-time, but we were scared that that server might be off-line.
The prpblem mentioned in the article is that often, a compromised desktop has root access to a server, which has access to another server, and so on. With proper key management, access to (a former employee's?) desktop shouldn't grant access throughout the network. Too often, keys aren't properly managed, so an intruder can go from one machine to another, all over the network.
I use a tiny script: https://github.com/bronson/sshkeys
Makes the easy even easier.
Was wondering who "Tatu Yionen" was...