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?


4 Answers 4


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
  • Hackers brute force passwords using literally millions of hacked devices. fail2ban is mostly useless nowadays. Jul 24, 2022 at 18:16
  • 1
    fail2ban is mostly useful for password auth as a means of preventing brute force attacks against sshd. I would discourage using fail2ban on key auth only ssh servers, as it increases the attack surface of the server while not providing any useful function.
    – ndt
    Jul 24, 2022 at 22:18

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.

  • 2
    In my opinion, this answer is flawed. Either you consider SSH easily exploitable and then by changing port you are just relying on Security Through Obscurity or you consider SSH secure (as reasonably as any software can be) and you just change port to make your OS automatically stop the flow of connection attempts. Quoting Matrix as proof of SSH vulnerability is just ridiculous (especially when using an SSH 1 exploit). This is what a real hacker movie would look like. Jul 24, 2022 at 13:24
  • I said, "you make yourself a little bit more secure against possible future attacks as you will have time to upgrade before you get owned" - nowhere in my answer I gave the idea that's a method of preventing attacks. You read what you want to read and disagree. OK. Your choice. Just don't use it against me and don't use it against facts. Jul 24, 2022 at 18:17
  • Not using anything against you :) It's just that I think running ssh on a different port is done mostly to filter out the bots looking for the low-hanging fruits. In case of a serious exploit like the CRC32 one, it is hard to say how much a different port can help. But you are right it may buy some time and shield from the very first wave. I don't think it'll buy much time considering services like shodan and massive port scanners, so I consider it a small addendum rather than the primary reason to move sshd to another port. Jul 25, 2022 at 14:13
  • how much a different port can help a different port likely means you're not going to be among the first being attacked which can give you time to upgrade and fix a future vulnerability. Jul 25, 2022 at 17:44
  • That Matrix scene was from Matrix Reloaded (the second movie, not the original) and yes, it portrayed a real exploit. @MargaretBloom had a nice visual depiction of hacking/coding. My favorite is Squirrel Girl's programming montage.
    – Adam Katz
    Jul 25, 2022 at 18:27

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 ( rather than all interfaces ( 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.


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:)
  • I really like the idea of limit access by IP, I'm just worried my ISP will change my IP some day and I won't be able to get in. Maybe that's silly these days.
    – isaaclw
    Apr 28 at 21:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .