They were also never portrayed as such - merely an additional layer of protection
It's not an additional layer if you replace passwords with keys.
It allows you to step in the middle of the process - it's not simply a question of dropping a file in ~/.ssh/ with no checks. Since the user can't use any key they want this allows you have, say, a process of requiring a decent password, stashing the public key somewhere else, making the private key file immutable to prevent password changes or removal, and record an audit log entry (all of which could be done by an ssh-keygen wrapper).
Which implies that you're controlling both the client and the server, which begs the question of why you're exposed to attacks from random hosts in the first place...
All of which is irrelevent - we're comparing it to plaintext authentication, where our hypothetical attacker already has their password without having to brute force anything. It also requires you to have a copy of the keyfile in the first place, which is harder than firing up an ssh brute-force bot.
So you're comparing a MITM password attack to a secret key brute force
attack. Apples and oranges, anyone?
Right, but in the real world password policies don't work so well because normal humans don't handle high-entropy passwords well and they're going to find an algorithm which your policy doesn't catch,
So? If you can't figure out the algorithm with brute force attacks (e.g., cracklib) it's fairly likely that an attacker using the same techniques can't either--which means that the password policy takes care of the attack we started out talking about at the start of the thread. These worms aren't using secret password cracking mojo, they're largely trying things like account guest/password guest and other trivially preventable problems. The compromises I've seen due to these ssh worms that are going around have *all* been on systems that didn't enforce strong password policies. That's why I find it vaguely humorous when people suggest that replacing the passwords with ssh keys is the right solution and then wave their hands about the key management problem. The tools and (admin/user) education needed to enforce password practices are *trivial* to implement compared to the tools and education required to secure private keys properly. If someone didn't implement passwords well, suggesting that switching to ssh keys without doing else will solve their security problems is a bit, well, far-fetched. ssh keys *can* be an effective tools, but *only* after doing a good risk assessment, understanding and accepting the new risks that ssh keys bring, and coming up with a good plan for deploying and using them in a secure manner.
generate helpdesk traffic due to lost passwords
As opposed to forgotten key passwords? Seems like a wash to me.
and store it insecurely because they don't always remember it.
Insecure storage is at the heart of the problems with ssh keys--you can't (with any sort of credibility) argue that users *can* store keys securely but *can't* store passwords securely.
That's not actually true for all ssh-agent implementations
And how do you control the client-side agent? The protocol allows it, so it's a vulnerability.
case, it's simply restating a point which was never in question: if the
Sure it was. At one point you (or someone) said that ssh keys were great because they couldn't be captured at intermediate hosts. But if you're forwarding the agent that attack vector is a wash.
The system I outlined above means that they can't simply use any random ssh key but, frankly, if your users are actively trying to subvert your security system you have bigger problems than script kiddies.
Welcome to real life. If your security relies entirely on users doing the right thing all the time you're going to get burned. A good security policy requires informed users but also some mechanisms to make it harder for people to screw up--unless your userbase is entirely infallible. (And I, for one, will welcome our new robotic overlords. :-)
Mike Stone
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
