Hell I'm not arguing security by obscurity doesn't have an effect. I do believe it does hide security vulnerabilities that can be attacked, but it's still security by obscurity.

>thus allows easier detection of worse attackers in server logs

I would be amazed if you could show me a single instance where people would see an attacker in server logs and act on it... quickly enough too that it's effective.

I'm pretty sure that it's extremely rare that anyone will look at logs, even small one, to catch theses kinds of situation. If that's really what you suggest as being an effective way to protect yourself, than that's what you should mentions that it's required to do to become effective.

Fail2ban will act noise or not... which was my point in my comment.

So first, moving the SSH port to something non-standard is not the only step in securing a machine. It's a filter.

On my little jump server at home I used to get tens to hundreds of login attempts per hour. The server only allows for pubkey authentication and my fail2ban rules were strict (block after a single failed login) so the probing never went anywhere. Unfortunately the block lists got huge if I set the block time to a meaningfully long period. It also kept my server at a constant low utilization.

I then started forwarding a non-standard port (that didn't end in 22) and the number of attempted logins dropped to a dozen in a week. I could set my f2b rules to expire after days and not see any performance impact from a big iptables blocklist. My server's baseline load also dropped since it wasn't dealing with constant noise. I could also set up alerts on failed login attempts since I wasn't getting inundated with noise.

I started with a secure setup and increased security by changing the SSH port. Less noise means I can actually see when things happen. It's an outlier event when I get a failed login on my server.

> I could set my f2b rules to expire after days

Why would you let the rule be shorter when the attack are more targeted? Doesn't make sense to me to lower it.

> not see any performance impact from a big iptables blocklist.

Wouldn't it be a pretty marginal performance impact? Let say you do get a performance impact significant, then the goal isn't security, it's performance. That's a new thing, performance by obscurity!

> I could also set up alerts on failed login attempts since I wasn't getting inundated with noise.

So you are looking for failed login attempts more now? I have an hard time believing this, but as I said in my previous message, if that was what made it more secure, it's a pretty important step to add, as I would ignore them whether it's 1000 an hour or 10 a week.

I'm curious, what would you even do if you were to see a failed attempt? At what point will you act and how would you act? Anything I can think of is meaningless.

Most distros have f2b's bantime and findtime set to ten minutes by default and a maxretry of 5. Those settings cover the script kiddies/bulk scans. Because of the short timeout your iptables block list isn't going to get too full for too long.

I set my bantime and findtime to much longer durations and maxretries to be 2. This means my iptables block list is long for long periods and f2b has to do more work looking through the SSH logs when dealing with the noise of listening on port 22. Both have non-zero effect on my little Atom powered jump server.

Cutting down the noise let me set even stricter f2b rules with far fewer resources being used on my server.

As for "doing something", there's not much to do for a failed SSH login attempt. I do send myself notification emails but those are just a small section of a larger status email. If I were to see a lot of login attempts on my random high port I'd likely take down external access to my server or set up VPN access to my home network.

My goal is to avoid background noise and get on a "not worth it don't bother" list.