Stopping Brute Force SSH Attacks - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: Stopping Brute Force SSH Attacks

    J> Right now, I can ssh to a machine and attempt to "brute force" my
    J> way into the system. All of the users on this system have
    J> ~/.ssh/authorized_keys2 files (and those keys have passwords).

No, they don't.  The keys in the authorized_keys* files are public keys
and are not password-protected or secret.  I assume here by "passwords"
you are referring to the passphrases on the corresponding private keys.
They are in no way relevant here; in order to mount a brute-force attack
against those passphrases, they attacker needs a copy of the private key

  Richard Silverman

Re: Stopping Brute Force SSH Attacks

Quoted text here. Click to load it

Quite true. Unfortunately, these are often easily stolen. In particular, a
lot of academic environments use un-authenticated NFS or SMB access to home
directories, often with the permissions set wide open "because we're an
academic environment and should be open". I suggest grabbing all NFS
accessible private keys as the sys-admin and checking them for
passphrase-less keys or for extremely stupid keys such as first name, last
name, and a few common passwords like :"love". In an environment of a 100
people, you're likely to encounter a few poorly protected such keys.

I've had people walk through the use of ssh-agent and unlocking their
protected private keys with me, then turn right around, go back to their
desks, and strip the passphrases off their private keys or even generate new
ones with no passphrase. It's a problem.

Site Timeline