6 ms·
For SSH simply disallowing passwords entirely removes this problem. For me that's the one single thing that dramatically improves defense against any kind of br
by fabian2k 5y ago
For SSH simply disallowing passwords entirely removes this problem. For me that's the one single thing that dramatically improves defense against any kind of brute force or untargeted attack.
- zinekeller 5y agoI'm actually shocked that you're the first one to mention it. Only use public key logins and if you're not targeted and if it's practical in your workflow change the port (definitely not for security, only so that sshd won't eat as much CPU time from bruteforce attempts).
- cube00 5y agoJust make sure you don't use a port any higher then 1024 or else a non root process can start up and take its place if the real one crashes.
- arc-in-space 5y agoOh, good to know, I will ignore this advice and excitedly await for this to happen to me
- Topolomancer 5y agoThat's an excellent point. I painted myself into a corner here because I am letting some of my friends use the server as well. Have to gently transition them to public key usage only now.
- bombcar 5y agoYou can restrict password auth to particular users/groups, which also greatly reduces the attack vector.
- Filligree 5y agoOr require OTP for password authentication.
- namibj 5y agoGive them a reasonable deadline, and just disable password login afterwards. This isn't something they should have trouble understanding/accepting.