Changing your ssh server’s port from the default: Is it worth it?

Changing my ssh port from the default port (22) has been one of my standard processes for quite some time when I build new servers or virtual machines. However, I see arguments crop up regularly about it (like this reddit thread or this other one).

Before I go any further, let’s settle the “security through obscurity” argument. (This could probably turn into its own post but I’ll be brief for now.) Security should always be applied in layers. This provides multiple levels of protection from initial attacks, like information gathering attempts or casual threats against known vulnerabilities. In addition, these layers of security should be applied within the environment so that breaking into one server after getting a pivot point in the environment should be just as difficult (if not more difficult) than the original attack that created the pivot point. If “security through obscurity” tactics make up one layer of a multi-layered solution, I’d encourage you to obscure your environment as long as it doesn’t affect your availability.

The key takeaway is:

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

Let’s get back to the original purpose of the post.

The biggest benefit to changing the port is to avoid being seen by casual scans. The vast majority of people hunting for any open ssh servers will look for port 22. Some will try the usual variants, like 222 and 2222, but those are few and far between. I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile.

If it’s more difficult to scan for your ssh server, your chances of being attacked with an ssh server exploit are reduced. A determined attacker can still find the port if they know your server’s IP address via another means (perhaps via a website you host) and they can launch attacks once they find it. Paranoid server administrators might want to check into port knocking to reduce that probability even further.

Remembering the non-standard ssh port can be annoying, but if you have a standard set of workstations that you use for access your servers, just utilize your ~/.ssh/config file to specify certain ports for certain servers. For example:

Host *
  Port 4321
  Port 2345
Host *
  Port 5432

If you run into SELinux problems with a non-standard ssh port, there are plenty of guides on this topic.. The setroubleshoot-server package helps out with this as well.

# semanage port -a -t ssh_port_t -p tcp 4321
# semanage port -l | grep ssh
ssh_port_t                     tcp      4321,22

Here is my list of ssh lockdown practices when I build a new server:

  • Update the ssh server package and ensure that automatic updates are configured
  • Enable SELinux and allow a non-standard ssh port
  • Add my ssh public key to the server
  • Disable password logins for ssh
  • Adjust my AllowUsers setting in sshd_config to only allow my user
  • Disable root logins
  • For servers with sensitive data, I install fail2ban


  1. Paul Querna says

    Why is the port important at all? I’m not even concerned about layers; I trust cryptography and the basics of sshd’s implementation — so assuming sshd is configured for public key auth only — I don’t really care about the port.

  2. Robot Terror says

    Paul: the problem isn’t with SSH keys or even strong passphrases;’it’s that open ports are answered by running processes. Those processes are programs and can have exploitable weaknesses. One doesn’t have to break cryptographically strong keys to exploit a bug in the ssh daemon.

  3. says

    I’m in the “not worth it” camp. I recently read somewhere that in order to be acceptable security by obscurity the secret should be:

    1. Small
    2. Easily changed
    3. Known by very few people

    A custom ssh port is certainly a small piece of info. But it is not easily changed, especially in larger organization where everyone has to put the port in their .ssh/config as well as every other process that might involve ssh.

    It is also not known by very few people as everyone who has to use ssh has to know the port.

  4. Jonathon Sisson says

    Why not just use iptables or pf built-in rate limiting? No more fail2ban, no more random ports, no more port knocking nonsense. I have a simple setup on my home firewall (OpenBSD/pf) that adds an ip to a “abuse” table once the ip exceeds a given rate of connections on port 22. Sure, a determined attacker can simply slow the rate down, but a determined attacker can also find a different port or sniff out port knocking…and no extra fluff (like python) is required using the “in-house” toolset.

  5. Michael Lausch says

    Changing ssh port to 443 also allows me to tunnel SSH through some web proxies.

  6. Stevko says

    I know people, who put ssh on port 443, not because it increases security, but because there are networks that block everything except ports 80 and 443.

  7. Nils Breunese says

    “For servers with sensitive data, I install fail2ban”

    Why not all servers?

  8. oxtan says

    Not worth it. Just enable iptables with the recent module like this:

    -A INPUT -i eth0 -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 5 –name DEFAULT –rsource -j ULOG –ulog-prefix “blocked”
    -A INPUT -i eth0 -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 120 –hitcount 5 –name DEFAULT –rsource -j DROP

    We deploy this kind of stuff to our servers with cfengine. Very simple once you have the infra set up.

  9. eshh says

    I used to always do this , but have over the last year migrated to a iptables,fail2ban + GEO-IP solution . No need to get ssh requests from Korea,China or Brazil hehe.

  10. Aaron Culich says

    For port knocking I’d recommend trying out fwknop:

    Here’s a summary snippet from the website:

    fwknop stands for the “FireWall KNock OPerator”, and implements an authorization scheme called Single Packet Authorization (SPA).

    With fwknop deployed, anyone using nmap to look for sshd can’t even tell that it is listening; it makes no difference if they have a 0-day exploit or not.

    Try it out with: sudo apt-get install fwknop-client fwknop-server

  11. tux9656 says

    Let’s say that changing the port does not increase security at all. With that said, it is still worthwhile to change the port. With less automated attacks on you ssh server, your log files won’t fill up as much, and it reduces load on your server by not having every ssh attack script knocking on your server’s door.

  12. crazy chain says

    I like the hit count approach if you need to travel and administer from multiple source IP addresses or you don’t want to track them.
    For a small organization using iptables, a small custom chain with acceptable IP addresses might be a quick solution. This might be too constricting for some, but should be compact and perform well.
    iptables -N my-custom-chain
    iptables -A my-custom-chain -s safe_ip -j ACCEPT
    iptables -A my-custom-chain -j DROP

    iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -j my-custom-chain

Leave a Reply

Your email address will not be published. Required fields are marked *