Many server configuration guides recommend that the SSH port should be changed to something > 1024, for obscurity and to avoid conflicts.

This is interesting, because it recommends using a port < 1024, since it would be privileged:


Any thoughts on this practice?

  • 1
    No, because that's not the direction I was headed. It wasn't about the wisdom of changing the port, more about the narrow distinction between ports > 1024 and < 1024, which I'd never seen recommended before. The other guys are debating whether any of this is worthwhile, which I certainly understand, but again am just the messenger--this seems to be what most hosts (VPS) recommend doing. :) – SexxLuthor Aug 12 '14 at 16:47
  • So again, "This question may already have an answer here," as generated by SF above, is incorrect. The linked question does not discuss whether, should one decide to change the default SSH port, it should be changed to something greater than 1024, or less. The benefits of making this change at all are discussed here, and is also IMHO a very worthwhile discussion, but is somewhat tangential to the original question. This is not directed at the value of those answers, but strictly at this silly SF filter, and its adherents. ;) – SexxLuthor Aug 12 '14 at 16:51
  • 1
    @SexxLuthor I think the opening statement "Conventional wisdom holds that the SSH port should be changed to something > 1024" may very well be controversial enough in itself to move the focus away from your actual question. – Håkan Lindqvist Aug 12 '14 at 17:08
  • @stefan-lasiewski: Explain exactly how this question is a duplicate. Read my explanation above for why the auto-suggestion from serverfault is incorrect. You are all 100% WRONG. – SexxLuthor Aug 14 '14 at 2:20
  • @mdpc: Explain exactly how this question is a duplicate. Read my explanation above for why the auto-suggestion from serverfault is incorrect. You are all 100% WRONG. – SexxLuthor Aug 14 '14 at 2:21

You have different options. Each has drawbacks. So which drawback do you prefer?

  • Use port 22: You'll get lots of log entries from bots scanning for easy passwords. You can protect against compromises that way by only using public key authentication. But the log entries will still be there.
  • Some other port less than 1024: It will likely have been officially reserved for some other protocol, that can cause conflicts in case you'll ever use that protocol. There may be bots scanning for that other service, so you'll still see strange log entries show up occasionally.
  • Use port number 1024 or more: Local users can cause a DoS attack by listening on that port. They'll have to start listening while sshd is down, so there is a window of opportunity when sshd is being restarted.

If you otherwise keep your sshd secure, it seems you get the choice between getting logs flooded by remote hosts or DoS possibility for local users. The log entries could be mitigated through some sort of automatic blocking, which unfortunately open you up to potentially a different kind of DoS attack.

| improve this answer | |

Well, you could change the port from 22 to something different, yes. But that's nothing a port scan won't show in the end.

If you are concerned about security and SSH, disable password only authentication at all. Also turn on a monitor log scanner, like fail2ban, configured to ban malicious hosts who run their scans on your site.

And if you are even more concerned about security, then there's one thing where changing the port makes sense: change it to something uncommon and implement port knocking!

Changing the port only does not do much at all, changing the port with active port knocking is a wholly different kind of matter!

| improve this answer | |
  • 2
    Why would you change the SSH port if you already implemented port-knocking? Port scan will still fail and after the correct knock-sequence you can still do a scan. I'm just curious or is this the solution for the ultra-paranoid people? :D – Broco Aug 12 '14 at 16:41
  • @SexxLuthor I'll upvote this for you :D – Broco Aug 12 '14 at 16:44
  • Well Boco, just because and yes, for the ultraparanoid, if you really, really want to be sure. – Marc Stürmer Aug 12 '14 at 16:45

Ports below 1024 are reserved for daemons and services that use CAP_NET_BIND_SERVICE by the Kernel, one of them is SSH.

In fact, changing the ssh port is not much of a security improvement, as a scan will still find open ports. You will have less log entries caused by attacks trying default passwords or password tables on the default ports of random hosts but if you setup your ssh right these shouldn't be a problem.

The problem is that connecting to your server from an environment where outgoing traffic is being restricted to standard ports you will have a problem. For me, keeping SSH on the default port is best practice but I guess there are some people willing to discuss that matter.

| improve this answer | |
  • Rainbow tables? Seriously? Rainbow tables has nothing to do with scanning for ssh servers to attack. First of all they only work if the password hashes leak. Secondly I don't think any of the OS you typically find ssh servers on were vulnerable to rainbow tables in the first place. – kasperd Aug 12 '14 at 18:22
  • Sorry my mistake I meant password tables. Those are tables filled with common passwords to have faster success than with brute force. I edited my answer accordingly. – Broco Aug 12 '14 at 18:39
  • 1
    Those are usually called dictionary attacks. – kasperd Aug 12 '14 at 18:41

I don't see any security advantage to changing SSH to a non-standard port. There's shouldn't be any conflict in staying on port 22, since that port is reserved for SSH. And if the security of your SSH server depends on it running on a non-standard port, you're not doing your job.

| improve this answer | |
  • Maybe he considers this not as an essential part of his defense, but only as a measure to lower the chance of a successful attack. – peterh - Reinstate Monica Aug 12 '14 at 16:34
  • @PeterHorvath I don't think any serious attack nowadays relies on default ports. nmap isn't that hard to use. – Broco Aug 12 '14 at 16:37
  • Thanks all, I'm just repeating what every guide for server configuration--for non-experts like me--recommends (in addition to disabling root and enabling key-based login). They seem to position this measure as @PeterHorvath has above: another step to reduce exposure. – SexxLuthor Aug 12 '14 at 16:37
  • And I imagine you and @Broco are correct--nobody who really knows what they are doing would be thwarted by this, but it in theory eliminates a certain percentage of attacks (script kiddies, etc.) P.S.: I'd upvote this answer but don't have 15 reputation score, so if you want to help a brother out... – SexxLuthor Aug 12 '14 at 16:39
  • @Broco Using nmap massively is resource intensive and attract attention. We don't know his actual situation. Using a zombie network on the free internet it can be ok, but for example on a corporate network it is extremely dangerous. I don't say it is an effective defense, I say only there are cases if this behavior can be reasoned. (I myself never do such service port changes because security reasons.) – peterh - Reinstate Monica Aug 12 '14 at 16:40

I have to partially disagree with the other answers because changing the port does not necessarily protect you against an actual targeted attack (in case which someone would be able to just scan all the ports and find the SSH one), but it does protect you against botnets that do bruteforce over random or selected hosts with dictionaries. And even in this case, I assume that every decent technical person will know to make sure that the passwords are strong enough, not to mention that newer installations of software actually do require you to have strong passwords. What I think that it protects you against are distributed denial of service attacks that could really get your server slow, fill the logs with crap and so on. While fail2ban & co. could do a nice job against a single host doing this, they are pretty ineffective against a really big botnet.

On the other side, I see no reason why you would leave your SSH port open to the Internet, unless you run something like a web host that provides SSH access or something. Otherwise, you should only allow very specific IPs that you trust to connect to SSH, this is THE BEST practice. Not port knocking, not changing the port, not fail2ban.

So, if you ask me, there are 2 options:

  1. You have a specific need to let SSH open for the Internet. In this case you would change the SSH port AND install fail2ban (maybe even set accounts to lock after X failed password attempts).
  2. You close SSH and whitelist only certain IPs.


Forgot about the over 1024 and under 1024 thing. Many firewalls indeed have specific rules that could make using a port under 1024 to have more sense. For example there are firewalls that deny connections incoming on ports higher than 1024 (so that you really need to have a service started with root or the required Kernel capabilities that listens to a port and not some exploit), other firewalls are giving more priorities to lower ports so that the system services can benefit of this etc.

| improve this answer | |

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