User: Password:
|
|
Subscribe / Log in / New account

Preventing brute force ssh attacks

Preventing brute force ssh attacks

Posted Oct 25, 2007 11:10 UTC (Thu) by nix (subscriber, #2304)
Parent article: Preventing brute force ssh attacks

An attacker that gets access to the private key corresponding to a public key in an
authorized_keys file on your system will have access to it *if and only if that key is
unpassphrased or they determine the passphrase*.

i.e. at worst passphrased keys are as insecure as passwords, and they're much more secure if
the remote host is not compromised itself.

(Unpassphrased keys should only be used inside a trust boundary, and even there with care:
it's best to use an SSH agent instead, and passphrase everything, but that might be tricky if
some of the keys are used by daemons, who can't reasonably ask a human to provide a passphrase
to the agent: if they provide the passphrase themselves, that passphrase becomes as tappable
as the private key, so passphrasing becomes pointless.

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. Of course the ability to
do that would itself be an information leak with security consequences...)


(Log in to post comments)

Preventing brute force ssh attacks

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

> 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.

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.

Preventing brute force ssh attacks

Posted Oct 25, 2007 20:00 UTC (Thu) by njs (guest, #40338) [Link]

>at worst passphrased keys are as insecure as passwords

Not true, unfortunately -- standard passwords can be (in practice) perfectly protected against
guessing attacks by using rate-limiting; there's no way to rate-limit attempts to guess a
compromised key's decryption passphrase.

Whether one cares or not is another matter (most of us are unlikely to be facing attackers who
are willing to spend the necessary time to crack a decent passphrase in any case, and
keyloggers and memory scanners are going to remain much cheaper and easier ways to get at
decrypted keys), but there are tradeoffs.

Preventing brute force ssh attacks

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

Hm. Interesting.

Of course the passphrase can be much stronger than a password (since you 
only need to type it in once in a blue moon thanks to ssh-agent), but even 
so, that's food for thought...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds