Unless you restrict SSH access to a small set of known-good IP addresses, of course.
back
2 comments
Fail2ban monitors more than just ssh. I uses it against http auth, suspicious http bots, and all sorts (I even have fail2ban watching irc connections on one box)
>>>(I even have fail2ban watching irc connections on one box)
Now you got me curious - watching what?
I've always wanted to do this, but then I thought "What if I suddenly lose my IP address?"
I'm always super paranoid about this too, but usually you can get back into a machine via console (if it's a virtual machine) or via KVM if dedicated.
But it still scares me too much...
Use ssh keys instead then :-)
Keys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password).
However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head.
Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt.
> Keys are additional credentials, so they don't add any security by themselves. You have remove a password from an account (set unusable password).
Keys add security if you turn off password based logins (this is done in sshd_config - you don't need to mess about with the users passwd)
> However, there are rare cases where you need to access the server from some remote location, when you don't have your SSH private key at hand, and the only credentials you can use, are the those you keep in your head.
> Obviously, the most important requirement is a strong password, but protecting against brute-force won't hurt.
You're point about not having private keys to hand is a very valid one; and why I opt for fail2ban ssh rules against password logins on my own personal servers. But the strength of keys compared to passwords does make key based authentication a good measure against brute force attacks (purely in terms of the time line to to crack a key)
Regarding the "don't have the keys" issue, I solve this with an encrypted TrueCrypt volume in Dropbox. Dropbox has 2FA set up on it, so getting into my servers requires 1) my dropbox password, 2) my phone, 3) the volume passphrase, and finally 4) the key passphrase.
As long as I have my phone on me, I can get into my servers, but am reasonably confident that a Dropbox compromise or phone loss would not result in my server credentials being compromised.