0

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?

David Mulder
  • 1,349
  • 1
  • 8
  • 16
  • 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 07 '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 07 '16 at 15:39
  • You create a bit of a logical paradox in your reasoning, and your premises are strange. Yes, simply "hiding" the port offers little security, but it does lower your attack surface. Yes, complex passwords are harder to crack. But you know these things, so I'm really unsure what you are asking. You will also hit upon a case, if you extend the logic a bit, where a password is complex enough to run into the "usability" issue you talk about, so a key would ultimately be better. – schroeder Feb 07 '16 at 16:27
  • 1
    You seem to assume that you can control how users compose their password? – schroeder Feb 07 '16 at 16:40
  • @schroeder Nowadays SSH is only used by the same people who set up the servers. So yes, if you can tell someone to run on a non-standard port then you can tell someone that it's a bad idea too. And regarding what my question is: Is it pointless advice to run SSH on non-standard ports because it's just a weaker version of a secondary password. – David Mulder Feb 07 '16 at 16:54
  • 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 07 '16 at 16:59
  • @DavidMulder and what do you mean by "secondary password"? – schroeder Feb 07 '16 at 17:00
  • @schroeder That's odd, for end users I nowadays typically see GUI's deployed. I haven't seen a setup where end users where using CLI's in a decade except for legacy reasons. And with secondary password I simply mean that the port number becomes another bit of security of exactly the same type as the password, but weak because it doesn't have any of the security a typical password has. – David Mulder Feb 07 '16 at 17:44
  • 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 07 '16 at 17:48

4 Answers4

5

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.) If you're port-forwarding from a router that has no users, this risk is likely moot.

Serving on an alternate port is security through obscurity. Consider it "extra" but don't consider it when calculating entropy and risk. It's not bad to be obscure, but proper complexity measurement must assume all processes and schemes are known to the attacker. 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 password to password2938 (assuming you mean a standard random password), which I calculate would add 13 bits (a random dictionary word like whatever → whatever6823 increases entropy from 17 to 30). A 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 persistent attacks to trying an average of 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 more time that you'd have this account and password on this server (since you must never recycle passwords between hosts or even installs).

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.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
1

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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 01:48
1

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.

jcaron
  • 3,365
  • 2
  • 15
  • 22
1

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.

user1751825
  • 905
  • 4
  • 10