So, a pretty typical piece of advice is to run SSH on a high port number, thus decreasing the chances of it being attacked. The thing I have always wondered about though is that it seems more secure to run SSH on the standard port and just add an arbitrary number between 1.000 and 10.000 to the end of your password rather than using a non standard SSH port. My reasoning for this is that it adds the same amount of secrecy/obscurity (where I use the word 'obscurity' in the sense that passwords and keys are security through obscurity), however with a port as soon as you hit the correct number you receive confirmation from the server. With a password however you need the fully correct password before you receive confirmation.

Just to be very clear here, I am comparing the following two situations:

  • Username: user, Password: password2938, Port: 22
  • Username: user, Password: password, Port: 2938

and yes, I do know that using pubkey authentication is better, however it has certain disadvantages when it comes to usability (something which is not a valid concern on production servers, but is often a valid concern on private systems).

Is this reasoning correct and is the advice to run SSH on non-standard port numbers therefore incorrect/weak?

  • 4
    The question stems from an incorrect premise, and an omission. First, don't leave SSH protected by passwords. Ever. Second, you fail to consider the notion of 'privileged' ports. – Deer Hunter Feb 7 '16 at 15:37
  • @DeerHunter It is a premise directly assumed in the question so I will consider that comment of yours as blatantly offtopic. And privileged ports would only argue even more in favour of leaving SSH running on port 22. – David Mulder Feb 7 '16 at 15:39
  • 1
    You seem to assume that you can control how users compose their password? – schroeder Feb 7 '16 at 16:40
  • 3
    "Nowadays SSH is only used by the same people who set up the servers." I have dozens of servers at my workplace alone where that is not the case... Again, your premises and underlying assumptions are a little strange, and it makes the question difficult to answer. – schroeder Feb 7 '16 at 16:59
  • 2
    Not everyone who needs ssh access and who didn't set up the server is an end user ... So, can you explain how a "secondary password" in your parlance, is different from a randomly generated password? – schroeder Feb 7 '16 at 17:48

A password with increased complexity is great, but if there is an exploit against the server software (OpenSSH or otherwise) that you're running, it won't help. The idea behind an obscure high port number is that it won't be attacked in the first place, but there are caveats to consider:

High ports introduce an additional security risk. If the SSH server goes down, a local user can stand up a new SSH server on the same port. Only ports 1-1024 are restricted to the root user, so your alternate port should be in that range. (This cuts both ways: port scanners only examine these ports, so you're less hidden.)

This is security through obscurity and should be considered "extra" but it should not be considered a part of the security when calculating entropy and risk. It's not bad to be obscure, but it is bad to assume that obscurity provides sufficient security. Adapting a quote from @barbecue:

Obscurity is to security as camouflage is to armor.
One makes it harder to find you, the other protects you once you have been found.

You might get fewer attacks on port 2938, but a weak password is a weak password.

I really like your idea of comparing the password entropy of whatever to whatever2938 (*changed from password and password2938 for reasons noted below), which I calculate to be 17 bits vs 30 bits, showing that the longer password is certainly more secure, but in order to model this properly, you'd have to get statistics on how many port-22-bound attackers would eventually break that longer password versus how many attackers that would both find the nonstandard port and break the shorter password, and even that analysis would have to assume the same rate of persistence even though attacks are increasing in both frequency and sophistication.

Instead, I'd recommend something like Fail2ban, which can recognize failed logins and ban the IP that attempted them (by default, Fail2ban blocks an IP for ten minutes after ten failed logins within ten minutes, but this is all configurable). This limits attacks to trying one password a minute, so whatever would take about a week to break and even a more typical (yet still weak) password like Da5id would take 12+ years (222.6 ÷ 365 ÷ 24 ÷ 60 = 12) of non-stop password checking, which is presumably enough time to get you to notice the attempts in the logs.

Do not think that this makes weak passwords like Da5idRox a good idea. Fail2ban only runs on the SSH server; somebody with shell access would break this in two weeks.

Of course, there's nothing stopping you from doing it all. Add complexity to your password, use an alternate port, and block IPs with too many failures. An additional obfuscation technique you could try is port knocking, which can even be done securely if the knock itself is encrypted end-to-end or uses a one-time password.


* A minor note: I changed the question's sample passwords to use whatever rather than password because password is a special case. Common passwords like password (and simple variations) are best assumed to an entropy around 0–5, so e.g. p455w0rDz has an entropy of around 12, which is weaker than L%. In the above math, I've instead assumed you meant a random dictionary word, which has an entropy of 17 bits). More on password complexity calculations.

| improve this answer | |

I think there is problem with your comparison: while it is possible that every user on the system adds some chosen number to the password it is not possible that every user gets its own chosen SSH port. Therefore a different port can never be a replacement for a better password (and of course you should choose keys anyway).

Instead a different port is a way to reduce the attack surface by using obscurity. Since the usual scanning is done against the standard port you can hide your real server somewhere else and maybe even add some fake SSH server at the standard port to keep attackers busy away from your real server.

| improve this answer | |
  • The best way to keep a server secure, is to make it as invisible as possible. Any open port (fake or not) is a potential attack vector. You don't want to keep the hacker busy with your server at all, you want them to simply scan past and never give it a second glance. As soon as the server does anything of interest, it will be added to a list for further analysis. – user1751825 Mar 24 '16 at 1:48

Consider Joe the Script Kiddie.

Joe starts his ssh scanner script. This takes an IP address range, and goes on exploring all devices on that range, checking if port 22 is open. If it is, it assumes it's an ssh server, and can start trying to find usernames and passwords.

If your sshd is on a different port, you'll only be susceptible to scanners which do port scanning on top of (or instead of) IP scanning. Not saying that this will prevent any kind of attack on your server, but it will reduce your vulnerability to random scans of extended ranges of IP addresses.

| improve this answer | |

Using secure passwords is a given. This must be done regardless of port number. I don't understand why this should be mutually exclusive. Use a high port number, and use a secure password.

If you run a publicly accessible ssh server on port 22, it will absolutely be hammered by hack attempts. Even if nearly all of these attempts are completely ineffective because of your secure passwords, they will still clutter up your logs, making it harder to detect more serious attempted intrusion.

Yes it's security by obscurity, but it still helps. The vast majority of bots will simply never even see your server.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.