Should I change the default SSH port on linux servers?

Question

Is there any advantage in changing the SSH port, I've seen people do that, but I can't seem to find the reason why.

If you have a strong password and/or a certificate, is it useful for anything?

Edit:

I should also mention that I am using iptables rules to limit brute forcing attacks, only 5 login attempts are allowed per minute per IP address.

Answer 1

The Internet is a wild and scary place, full of malcontents whose motives range from curiosity all the way to criminal enterprise. These unsavories are constantly scanning for computers running services they hope to exploit; usually the more common services such as SSH, HTTP, FTP, etc. The scans typically fall into one of two categories:

1. Recon scans to see what IP address have those services open.
2. Exploit scans against IP addresses who have been found to be running a specific service.

Considering how large the Internet is it is typically infeasible to look on every port of every IP address to find what's listening everywhere. This is the crux of the advice to change your default port. If these disaffected individuals want to find SSH servers they will start probing each IP address on port 22 (they may also add some common alternates such as 222 or 2222). Then, once they have their list of IP addresses with port 22 open, they will start their password brute force to guess usernames/passwords or launch their exploit kit of choice and start testing known (at least to them) vulnerabilities on the target system.

This means that if you change your SSH port to 34887 then that sweep will pass you on by, likely resulting in you not being targeted by the followup break-in.

Seems rosy right? There are some disadvantages though.

1. Client Support: Everybody who connects to your server will need to know and use the changed port. If you are in a heavily managed environment, this configuration can be pushed down to the clients, or if you have few enough users it should be easy to communicate.
2. Documentation Exceptions: Most network devices, such as firewalls and IDSes, are pre-setup for common services to be run on common ports. Any firewall rules related to this service on this device will need to be inspected and possibly modified. Similarly, IDS signatures will be tweaked so as to only perform SSH inspection on port 22. You will need to modify every signature, every time they are updated, with your new port. (As a data point there are currently 136 VRT and ET snort signatures involving SSH).
3. System Protections: Modern Linuxes often ship with an kernel layer MAC and/or RBAC systems (e.g. SELinux on RedHat based or AppAmor on Debian based) and that are designed to only allow applications to do exactly what they're intended to do. That could range from accessing the /etc/hosts file, to writing to a specific file, or sending a packet out on the network. Depending on how this system is configured it may, by default, forbid sshd from binding to a non-standard port. You would need to maintain a local policy that would allow it.
4. Other Party Monitoring: If you have an external Information Security division, or outsource monitoring, then they will need to be made aware of the change. When performing a security assessment, or analyzing logs looking for security threats, if I see an SSH server running on a non-standard port (or an SSH server on a non-UNIX/Linux for that matter) I treat it as a potential backdoor and invoke the compromised system part of incident handling procedure. Sometimes it is resolved in 5 minutes after making a call to the administrator and being told it's legitimate, at which point I update documentation, other times it really is badness that gets taken care of. In any event, this can result in down-time for you or, at the least, a nerve racking call when you answer your phone and hear, "Hi, this is Bob from the Information Security Office. I have a few questions for you."

Before changing your port you need to take all of this into account so you know you're making the best decision. Some of those disadvantages may not apply, but some certainly will. Also consider what you're trying to protect yourself against. Often times it is simply easier to just configure your firewall to only allow access to 22 from specific hosts, as opposed to the whole Internet.

Answer 2

Yes it can be, not by increasing security but you can reduce the amount of failed login attempts on your server. I always change my default ssh to reduce the warnings I get from ossec. Also if you use a really random port and someone still tries to access your machine, chances are higher that it is a targeted attack rather than a random scanner.

Answer 3

As others said, putting SSH on a port other than 22 will make more unlikely to be hit with a random scan. You will be targetted if the attacker is trying to get your server, not any server.

I have a server with ssh bound to a random high port. And I have a ssh honeypot on port 22, that will reply to any and every login attempt with a 'access denied' message.

I don't think it's a defense by obscurity, but defense in depth: to attack my server, the attacker must first find the port. If I have a few fake honeypots (lots of ports redirecting to the same honeypot), the attacker will hit a lot of fakes and have no way to know if it hit the real ssh or not.

It's only the defense, though. I have portsentry active too, so if someone try a portscan, they will be blocked for an hour. If they bruteforce the password on the right ssh, they will receive 'access denied' for an hour. If they successfully guess the password, they will be presented with a PAM prompt asking for the Google Auth token.

The cost of changing the port is very low, and I think the downsides are justified by the upsides.

Answer 4

Since most everybody talks mostly of disadvantages (which are real), I'd like to share several advantages here:

• you really want to avoid automated attacks. Unless your are a high-profile user, vast majority of attacks will not be targeted to you, but automated best effort attacks which would just try default ports. Avoiding them helps in several ways:

  • you reduce attack surface (most automated attacks)
  • you reduce your exposure due to bugs in sshd or crypto libraries it uses
  • some bugs like heartbleed allows for exploiting your servers just by connecting to an open port, even without knowing any passwords or keys. By using non-standard ports you avoid this.
  • some bugs like weak private keys allows automated attacks to 0wn your server before you apply the patches. Using non-standard ports again avoids that first waves of attackers and gives you more time to patch.
  • you reduce clutter in your logs, which saves you a lot of admin time when reviewing logs, allowing you to concentrate your efforts on more problematic targeted attacks
  • it provides better protection with less work than kludge which you mention in update (blocking IP after 5 incorrect logins - which will allow some of the attacks especially if IP keeps changing; especially in IPv6 world where each attacker will have billions of them to spare; and the kludge can produce false positives locking out legitimate users and producing more support calls)
  • sometimes, even good passwords will get compromised (via some other bugs elsewhere, perhaps, or careless users entering them on keylogged machines) and stored in dictionaries used for attacks later. Again, random port will avoid vast majority of this class of automated attacks (most keyloggers will save just username/password pairs, and not go looking for ports in configs).

• whatever the attacker does not expect, it always either turns him off completely, creates more work for him, or makes you a less interesting target. And it also increases your time for detecting and defending against attack.

• running on port >1024 does not require sshd to run as root, which allows for running it is only one user for which it is needed, avoiding one whole class of bugs (true even when some sshd implementations take extra care to run with lowered privileges when not needed).

Answer 5

Changing the port only stops automatic attacks against your SSH and some script kiddies. If someone was targeting you then they could fine the new SSH port. The advantage is that it stops failed login attempts in your logs. I typically have something like Logwatch and SSH on a different port running with PasswordAuthentication set to no in my sshd_config.

Answer 6

I suppose it depends on how up to speed you are going to be on patching your server and whether you have any kind of firewall in-front of the server.

If you are leaving the server open to the world and don't have anything setup to alert you or to autoinstall OpenSSH patches then I would suggest moving the server to a random high numbered ports.

Ultimately though just moving the port number doesn deter everyone, sure it deters the script kiddies that are just checking port 80, 22, 23 etc but not if someone were to do a 1-65535 scan.

Answer 7

As others have already noted, changing the default SSH port doesn't gain you much from a security perspective. However, it can still be of advantage to do so if you intend to connect to the machine from a network where the administrators have locked down port 22. (Many schools, workplaces, and free WiFi hotspots block all outgoing traffic except that on the default DNS, HTTP, and HTTPS ports.) In this case changing your SSH port to 53, 80, or 443 (or having your router forward one of those ports to 22) will usually allow you to ssh into your machine when studying/working/travelling.

In rare cases these networks may not be simply blocking ports, but also inspecting the traffic to filter out ssh connections. For this situation you need to investigate other alternatives.

Answer 8

This is something of a philosophical question: "is control X helpful?" And as the best answer pointed out, you should also consider "what are the costs (client support, doc exemptions, system support, monitoring support, and I'd throw in direct costs, licensing costs, etc) of control X?"

Anything is helpful in certain contexts. It is a good idea to ask yourself what context you are in. Sometimes the context is one of compliance -- you are deploying control X to meet a particular requirement. "I've got to move my ssh port because system policy forbids listeners on port 22." Then either do it, file for an exception, or work to change the policy. [That would, imho, be an unwise policy.]

Here, the context is probably "I'm a random guy, with a host on an uncontrolled network, and I don't want to lose control of my box." Attacks always have an investigation phase -- if the investigation is "send a SYN on port 22 and see who answers" then you are protecting against that specific threat vector. (If the investigation is "perform a port sweep, collect banners, and see if anything interesting shows up" then your control is of no effect.) But now you have made a lot of work for yourself -- if you are using a tool to attach to the server, you need to figure out how to work on that non-standard port -- and with some tools, that might not even be possible. On balance, and in this context, I wouldn't recommend changing ports.

One benefit noted was reduction of log events associated with false positives. I actually find that a negative! The steady stream of inbound attacks on port 22 can actually be helpful -- if they stop, you know that there is a problem with your Internet feed. I think the perceived benefit is a false one -- the right answer is to tune your anomaly detection system to filter out unsuccessful login attempts from external networks.

Answer 9

Changing your ssh port to something very random can help. As many said it will really only help against random attacks (even still some random attackers will find you) and if someone is after you then they will find your ssh port.

Someone mentioned the problems with not using 22 for large organizations. Even for small to medium orgs you should have an internal network and the ssh port can be open on port 22 even for password authorization. As a fallback mechanism, I think you should use a Match on the internal ip range to allow passwords if this is something that you need. If you are a large entity then I am assuming that you have resources so you can afford a vpn and you should have one. Then the issue with port 22 is less significant when there is no outside access.

If there is no internal network because there is only one server then it's not a big deal to handle the access on the other port for the one server.

It's worthy to note that ssh access on another port for regular workers offers better security at a convenience price because a vpn allows full access to the internal network. While ssh gives you almost the same thing, it is not automatic meaning that some random virus on your employees computer will need to forward a port to each resource that it wants to attack which is less likely.