Benefits of non-standard SSH port when password authentication is turned off

Question

Is there any benefit of using a non-standard SSH port when PasswordAuthentication is turned off in sshd?

The only benefit of non-standard SSH ports I know of is a reduction of the amount of brute force attempts since most scanners only attempt logins at standard ports. But as far as I know, brute forcing a private key is practically impossible. So it seems to me that this benefit does not apply when authentication is only possible via a private key. Is there any reason I might want to do it anyways?

Answer 1

You are focused in the wrong direction.

If you are running a publicly accessible SSH port, you should also be running fail2ban (or the equivalent) to handle brute force attempts.

Whether you want to use a non-standard port has pros and cons:

• (Con) Some applications don't play well on non-standard ports
• (Pro) Some internet providers block standard server ports for non-business accounts

Answer 2

The only benefit of non-standard SSH ports I know of is a reduction of the amount of brute force attempts since most scanners only attempt logins at standard ports.

Exactly it's about not getting hundreds of failed SSH attempts daily in your system logs. That's the reason in our org and for my PC which has a direct Internet connection we've changed the default SSH port to something different. I still recommended to use the port under 1024, e.g. 911 because that's the only way to make sure some rogue application running on your PC doesn't take over your actual SSH port/daemon.

brute forcing a private key is practically impossible

Nothing that I'm aware of.

Is there any reason I might want to do it anyways?

SSHd has been exploited beyond authentication, i.e. it has had certain programming errors which allowed to bypass authentication completely (such a thing was demonstrated in the original Matrix movie), so by not running it on the default port you make yourself a little bit more secure against possible future attacks as you will have time to upgrade before you get owned.

Answer 3

As others have stated, running on a nonstandard port keeps failed login attempts out of your logs.

However, I would discourage running sshd on a nonstandard port. Running network services on standard ports helps keep your networks understandable. In the middle of an incident (availability or security), you don't want to waste time trying to reverse engineer which services are running where. Simplicity is an important part of a secure network, and standard ports are simple. It's rare that an attacker who would have compromised your system would be stopped by a nonstandard sshd port, but users of your systems will be confused by nonstandard ports.

If you start running tooling that does automated traffic analysis in your networks, you'll want to be using standard ports. Traffic analysis tools already have rules for standard ports.

If you want to keep failed attempts out of your logs, run wireguard and require an active wireguard tunnel to access sshd. You can achieve this by binding on localhost (127.0.0.1) rather than all interfaces (0.0.0.0). Unlike sshd, Wireguard makes a number of design decisions that make annoyances by unauthenticated users more difficult.

Wireguard is designed like a state machine driven by timers. Once the timer fires, the state machine advances to the next phase. Without the key material, very little to no influence in the activity of these state machines is possible. You won't find log spam. It's a super minimal attack surface with modern cryptography.

If you don't want to figure out how to set up wireguard, Tailscale is a proprietary tool that will do most of the heavy lifting for you. Most engineers I speak to remark (with much surprise) that Tailscale takes only 15 minutes to set up. It uses wireguard as the transport layer but offloads key distribution to the wireguard servers.

The goal here is to avoid exposing sshd to the public internet. Changing the port from 22 to 2222 obfuscates the behavior of your server, but putting sshd behind wireguard ensures that only users with the correct wireguard key may access sshd. It's a stronger means of achieving the same goal.

Answer 4

That would probably decrease number of spam in your logs and save you from script kiddies, but it has nothing to do with real security: it is more like security through obscurity approach. But every little bit helps, so you can do that.

To secure SSH I suggest to:

• Limit access by IP. Do you really want to access your server from any IP address or you probably know for sure all IP addresses you are going to use? In latter case, use ipset list and simply DROP access from any other IP. Even if you do not know IP, you still know the country, right? There are lists of networks for each country, so you can only open ssh for your country.
• Use fail2ban: no reason to pollute your logs with zillions of auth failures: just DROP traffic from IP after 2-3 failed attempts.
• Obviously, deny passwords and root access: only use keys (as you already do). It is next to impossible to crack modern key. I prefer ed25519. Keys must have passwords (passwordless key could be stolen)
• Check your ssh with https://sshcheck.com/ (open firewall for a while for it): that will help you to remove outdated cipher suites.
• Monitor your logs with tools like Logwatch, so you would know if somebody attacks you by brute force.
• Keep OpenSSH up-to-date:)