Charlie Harvey

SSH: to change port or not to change port

There are strong opinions on whether to run your SSH daemon on ports other than the default 22. On the pro side, the argument is that most automated tools only check port 22, so you reduce your exposure to random script kiddies by not running it there.

That’s just security by obscurity say the anti side. If your sshd is locked down properly then it shouldn’t matter how many people come knocking. What is important is that you don’t let them in.

Why a non-standard port?

The principle that comes into play here is, perhaps best illustrated by an oft-quoted aphorism

You don’t have to run faster than the bear to get away. You just have to run faster than the other guy.

Having ssh run somewhere where automated tools can’t see it reduces your attack surface. In an experiment run by Major Hayden the amount of casual scans dropped by 98%. That is a non-trivial amount of network traffic and server resources.

Running on a different port doesn’t stop you from taking the normal security measures:

  • Running DenyHosts or Fail2Ban
  • Disallowing root logins
  • Locking logins down to named users

In fact it means that you could set up a rule to ban any IP that hit port 22, because you would know that it was illegitimate traffic.

Why not?

[Security] should not require secrecy, and it should not be a problem if it falls into enemy hands

So runs what has become known as Kerkhoff’s principle. Advocates of keeping sshd on port 22 observe that changing port is just security by obscurity. Of course this is something of a straw man argument, very few sysadmins advocate only changing the port to secure ssh.

A stronger argument is that non-root users can start processes on ports higher than 1023. Someone who had access to the system could start a bogus login on your non-standard ssh port and grab your password as you logged in. This would be even worse if you allowed root logins. It would allow a privilige escalation.

Next: running on a different port is inconvenient. You have to remember to type -p222 when you ssh to a box (or, more sensibly change the port in your ssh config. I have some sympathy with this argument, though it is not really a security argument. Unless we argue from another of Kerkhoffs priciples for military ciphers.

Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules

Lastly a better solution to the mitigating attacks than changing ports is to use port-knocking. This is a pretty strong alternative way to stop automated attacks. But it is also a bit inconvenient, perhaps more so.

My take

I generally favour running on a non-standard port. Reducing the attack surface of boxes does not mitigate the risk of a targetted attack, but it does help preserve server resources for their intended use. I am in no way arguing that just changing the port is a good idea. But in combination with other measures it can help.

Security through obscurity is effective if it’s one layer in a multi-layer security solution

If you were concerned about the fact than non-root users could run something malicious on that port, then running on a port less than 1024 would mitigate the problem. Using keys rather than passwords as your login mechanism is a good practice anyway and also helps to protect against that attack.

I cannot argue that running on another port is not less convenient. One big thing that irritates me about using a different port is that ssh, scp and sftp all have different ways of specifying the port (-p222, -P222, -oPort=222). That is a right pain. However, as so often in security, changing port is a trade-off and the amount of extra overhead it imposes is small. Similarly with port-knocking, if you are against running on a non-standard port.

One thing that I hope everyone will agree with is that changing (or not changing) the port is just part of the work you need to do to protect your ssh. If your threat model involves mostly targetted attacks or if you aren’t too concerned about using server resources to respond to automated scanning tools, then it’s no biggie to run on port 22.


  • Be respectful. You may want to read the comment guidelines before posting.
  • You can use Markdown syntax to format your comments. You can only use level 5 and 6 headings.
  • You can add class="your language" to code blocks to help highlight.js highlight them correctly.

Privacy note: This form will forward your IP address, user agent and referrer to the Akismet, StopForumSpam and Botscout spam filtering services. I don’t log these details. Those services will. I do log everything you type into the form. Full privacy statement.