> > > Doesn't that seem a little overkill just for controlling logs?
> > Someone spamming your SSH listener is bad for other reasons, and blacklisting obvious ne'er-do-wells is never overkill.
> If it is, you've got something seriously wrong with your setup. You should make fixing that your first priority.
Are you describing a Debian server instance running an SSH daemon listening on a public IP address as "something seriously wrong?" Are you implying that DoS and brute force attacks are not real threats? Is there another solution you prescribe to address these and related issues other than the solutions discussed in this thread, such as fail2ban, port fluxing, port knocking, and VPN?
> > > To me fail2ban for SSH seems a little strange unless it's in a shared hosting environment, as the real solution is simply key auth.
> > Aren't most hosting environments shared these days? :-)
> Generally not, and that'd obviously only apply if you were operating the environment as generally only the host has root on such systems.
If you don't own and operate your own data center, which is becoming a rare thing these days, your servers are in a shared hosting environment. How do you define "shared hosting environment," and how is fail2ban "a little strange" unless in that context? What does root access (or the lack thereof) have to do with protecting daemons from network attacks?
>Are you implying that DoS and brute force attacks are not real threats?
Brute force should not be, we have key auth to prevent that. Use it. If you're using fail2ban to prevent DoS attacks you probably shouldn't be the person trying to prevent DoS attacks.
>Is there another solution you prescribe to address these and related issues other than the solutions discussed in this thread, such as fail2ban, port fluxing, port knocking, and VPN?
Key auth to stop brute forcing, VPN would be preferable to mitigate potential key compromise.
>If you don't own and operate your own data center, which is becoming a rare thing these days, your servers are in a shared hosting environment. How do you define "shared hosting environment," and how is fail2ban "a little strange" unless in that context?
"shared hosting" is a pretty clear term, and anyone who's dealt with hosting should know what it means. But in case you don't, it's almost always used to refer to setups where you've got multiple customers hosting their content on unprivileged accounts on a shared server.
>What does root access (or the lack thereof) have to do with protecting daemons from network attacks?
You need root for fail2bans SSH blocking to function.
Someone spamming your SSH listener is bad for other reasons, and blacklisting obvious ne'er-do-wells is never overkill.
> unless it's in a shared hosting environment
Aren't most hosting environments shared these days? :-)