Re: Darn skiddies (ssh login attempts)
Michael Stone wrote:
Depending on the attack. That's the point I'm making--rsa keys protect
against certain attacks but do absolutely nothing about other attacks
and shouldn't be seen as a magic bullet.
They were also never portrayed as such - merely an additional layer of
protection which has the side benefit of completely blocking some very
widespread attacks.
Central distribution is also quite easy and allows you to decide how
much control you want over the process - simply change the authorized
key path to a directory which isn't user-writable and use your
existing management tools to synchronize changed keys.
Dude, that does *nothing* to manage the private key.
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).
Only if the key wasn't protected with a password - sure, it's possible
for an attacker to brute-force the key but that's a lot more work than
they'd have to do if you're using password authentication and it gives
you more time to detect the intrusion and get users to change their keys.
Huh? You do realize that the passphrase on the private key can be brute
forced, and that it's possible to do so without connecting to the target
system at all?
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.
More importantly, good policy also tells users to use ssh-agent
instead of copying private keys all over the place - sure, not
everyone will do it but the same is true of password policies
No, password policies are enforceable--you control what the user can set
the password to. Key management policies are not enforceable.
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,
generate helpdesk traffic due to lost passwords and store it insecurely
because they don't always remember it.
The details aren't equivalent but the underlying problem is: you're
going to have to depend on your users cooperating with your policy; if
it's too onerous they'll find some way around it.
ssh-agent also intruduces another vulnerability in that new sessions
can be started using the secret key for authentication without the
user being aware that it's happening.
That's not actually true for all ssh-agent implementations but in any
case, it's simply restating a point which was never in question: if the
attacker has compromised the user's client they can already do anything
they want. If they can violate host security to abuse your ssh-agent
they can also capture everything else you do.
The easiest way is simply to replace ssh-keygen with a wrapper which
calls cracklib before passing the password to the real ssh-keygen.
This also has the advantage of reusing any existing cracklib policy.
Interesting. Now how do you keep the user from resetting their password
on any system where you aren't controlling the ssh-keygen?
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. You also
can't prevent them from writing their password down, giving it to their
office-mates, hard-coding it in a configuration file or storing it in
some app's weak password store.
Chris
Reply to: