Now I'm confused. Why do you consider blocking someone that clearly is trying to brute force his way in 'obscure'?

If you don't improve the 'hardness' of the authentication scheme - that is, if you continue to use a password instead of, say, SSH keys - then, for all intents and purposes, you've just made the system more _obscure_, rather than improving _actual_ security.

To be sure, a dedicated brute forcer could still brute force any system using f2b... it just might take a few months/years instead of a few days.

(However, as noted by other commenters, there's something to be said about obscurity within a system's overall security scheme. You just have to strike a balance...)

You're right, it's not.

It's not obscurity, it's rate limiting.

Obscurity is a perfectly legitimate and valid security technique.

Relying on obscurity alone is the mistake you are alluding to.

Why wouldn't you recommend using fail2ban and changing the port?

>Relying on obscurity alone is the mistake you are alluding to.

Ok, sure.

>Why wouldn't you recommend using fail2ban and changing the port?

IMO, changing the port will have nearly the same overall effect as f2b: minimizing the number of failed password attempts from unknown users.

To that end, changing the port is changing one value in a config file, which has the attractive advantage of being far simpler to setup + maintain.

I can confirm that changing the port does drastically reduce login attempts but also that it is not to zero, I had 45 yesterday, for instance but here's the kicker - all from the same IP.

Setup and maintenance are virtually zero though, for f2b. I know, I just installed it.

A one liner to install on most systems and updates along with everything else when your package manager does the updates.