Lax SSH Key Management A "Big Problem" 212
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."
His name is (Score:5, Informative)
Re:Passwords are a worse vulnerability (Score:5, 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
Re:Passwords are a worse vulnerability (Score:4, Informative)
use the Match config file directive:
PubkeyAuthentication yes
PasswordAuthentication no
Match Address 10.0.0.0/8
PasswordAuthentication yes
Re:who is doing this? (Score:5, 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.
Re:Inability of server to enforce policy (Score:4, 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".
Re:who is doing this? (Score:4, 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.