Preventing brute force ssh attacks [LWN.net]

Preventing brute force ssh attacks

Posted Oct 25, 2007 15:16 UTC (Thu) by madscientist (subscriber, #16861)
In reply to: Preventing brute force ssh attacks by nix
Parent article: Preventing brute force ssh attacks

> It would be nice if SSH had a way to refuse entry to unpassphrased keys, or
> if I had a way to determine that the private key corresponding to some
> public key were unpassphrased, so I could audit authorized_keys files for
> unpassphrased keys and remove them.

I don't see how this could work; the entire point of PPK is that you never have to hand out
your private key to anyone.  So there's no way that the server can see whether the client's
private key had a passphrase or not.

Of course the protocol could just include that information in the request but that's
completely useless as a security precaution, because the attacker just needs to tweak his SSH
client code to always say that the key was passphrased, even if it wasn't.

(Log in to post comments)

Preventing brute force ssh attacks

Posted Oct 25, 2007 16:27 UTC (Thu) by nix (subscriber, #2304) [Link]

Exactly: I don't think it's doable, although I sort of wish it was. The closest you can get is
to hack ssh-keygen so that it refuses to generate non-passphrased keys, and force everyone to
generate new keys, pissing everyone off.

Preventing brute force ssh attacks

Posted Oct 25, 2007 18:23 UTC (Thu) by madscientist (subscriber, #16861) [Link]

> The closest you can get is to hack ssh-keygen so that it refuses to
> generate non-passphrased keys, and force everyone to generate new keys,
> pissing everyone off.

Of course there's no way to guarantee that someone hasn't created a key using an older version
of ssh-keygen, or a version that's been hacked back again.  If the server cannot see the
private key it _cannot_ reliably know whether it was locked or not.  And not allowing the
server to see the private key is one of the key features of PPK.

Not to mention that there are very legitimate uses for password-less login, and non-PPK
password-less login has no security at all.  If you have to have password-less login (and
sometimes you do, particular for automation purposes) then using a passphrase-less private key
can, with proper attention to detail, give you a "pretty secure" way to do it.

Preventing brute force ssh attacks

Posted Oct 25, 2007 21:56 UTC (Thu) by nix (subscriber, #2304) [Link]

Yeah. What I'm really interested in here is being confident that an 
intruder who steals the private key of someone with login rights to my 
system cannot use it to log in... but I suppose even passphrases won't 
help there, as if they can steal a key they can almost certainly get root 
and install a keylogger, and the passphrase is toast.

Preventing brute force ssh attacks

Posted Oct 30, 2007 16:31 UTC (Tue) by droundy (subscriber, #4559) [Link]

> Of course the protocol could just include that information in the request but that's
> completely useless as a security precaution, because the attacker just needs to tweak his
SSH
> client code to always say that the key was passphrased, even if it wasn't.

Actually, this sounds very reasonable to me: the point of refusing access to passphraseless
keys isn't to protect from an attacker, but to protect from a lazy user, who doesn't want to
type his passphrase.  This wouldn't protect from sophisticated lazy users, but those lazy
users will probably realize it's easier to run an ssh-agent than to compile a modified ssh
client.  But this would prevent the stupid lazy user from logging in with his/her
passphraseless key, which ought to gain something.