5 ms·
To expand on this, don't use it because a good approach is to disable password authentication on SSH and use keys instead. If for some reason you still needed
by PUSH_AX 3y ago
To expand on this, don't use it because a good approach is to disable password authentication on SSH and use keys instead.
If for some reason you still needed password auth enabled I'd be inclined to still use f2b.
- ljm 3y agoEvery time I spin up a box by hand (which isn't often), I'll set up a sudo user with my SSH key, then drop out of the root shell and log back in as the new user. Only then will I disable root login and password auth over SSH and start setting up fail2ban and the like. If I lose access by, say, switching to a new computer and losing my SSH key, then I'm more or less dead in the water. But it's a small price to pay and 1password supports SSH keys first-class now.
- seanp2k2 3y agoat that point, why not just do FIDO2 with a YubiKey or something? eg https://www.ajfriesen.com/yubikey-ssh-key/ https://www.ajfriesen.com/yubikey-ssh-key/ as long as you don't lose the YubiKey or the backup YubiKeys you're good.
- ljm 3y agoI have one but getting it to work over WSL2 is a challenge
- elesiuta 3y agoI require both key and password to login, and have fail2ban rate limit password attempts. This gives sufficient notice to fix things if a key were to become compromised.
- Schnitz 3y agoI use it with ssh and password auth disabled, is there a reason not to? Might be overkill but the host is in my home so physical access if I ever get locked out is not an issue.
- elesiuta 3y agoI think this is still reasonable, attackers may have a database of leaked keys (e.g. if you ever accidentally commited to GitHub, or ever ran a malicious script which uploaded it), which they then try on random servers.