53

I've noticed that a lot of admins change the default ssh port.

Is there any rational reason to do so?

Improve this question
1

22 Answers 22

Reset to default
76

It isn't as useful as some people claim, but it will at least reduce the impact on your log files as many brute force login attempts only use the default port rather than scanning to see if SSH is listening elsewhere. Some attacks will scan for SSH elsewhere though, so it is no silver bullet.

If your server is going to be a shared host of some sort, rather than just serving the needs of your projects, using a non-default port can be a pain as you will have to explain it to your users over and over and over and over when they forget and their client programs fail to connect to port 22!

Another possible problem with SSH on a non-standard port is if you encounter a client with a restrictive out-going filter set, who can't connect to your custom port because their filter only allows, for example, ports 22, 53, 80 and 443 to be the destination for new out-going connections. This is uncommon, but certainly not unheard of. On a similar matter, some ISPs may see encrypted traffic on a port other than those where it is generally expected (port 443 or HTTPS, 22 for SSH, and so on) as an attempt to hide a P2P connection and throttle (or block) the connection in an inconvenient manner.

I personally keep SSH on the standard port for convenience. As long as the usual precautions are taken (strong password/key policy, restricting root logins, ...) it need not be a worry and the log file growth issue when you are hit with a brute force attack can be mitigated using tools such as fial2ban to temporarily block hosts that give too many bad sets of authentication credentials in a given space of time.

Whatever port you chose, if you do move away from 22, make sure it is below 1024. Under most Unix-a-like setups in their default config, only root (or users in the root group) can listen on ports below 1024, but any user can listen on the higher ports. Running SSH on a higher port increases the chance of a rogue (or hacked) user managing to crash your SSH daemon and replace it with their own or a proxy.

Improve this answer
2
  • I am the only user of this server. Thanks for clarifying the 1024+ issue. I would have used a 48xxx port if I choosed. Anyway at this point i still don't get if it's useful or not =/
    – dynamic
    Feb 7, 2011 at 16:41
  • 19
    +1 for the >1024 bit.
    – MattC
    Feb 7, 2011 at 22:01
29

It's a simple (but surprisingly effective) form of security through obscurity.

If your SSH server isn't on port 22 it's far less likely to get found by those scanning the whole internet looking for weak passwords on default accounts. If you're scanning the whole net you can't afford to check all 64k possible ports to find the SSH server.

However if someone is actively targeting you specifically it provides no benefit, since a simple one-off nmap scan will reveal the port on which it's actually running.

Improve this answer
13
  • 4
    "check all 64k possible ports"... Running SSH in any port above 1023 is just wrong. It makes the system more vulnerable than leaving it running in its default port.
    – Juliano
    Oct 9, 2010 at 14:14
  • 3
    @Juliano - please explain. Just because you have to be root to listen on a privileged port doesn't (AFAIK) make it insecure to run on an unprivileged port.
    – Alnitak
    Oct 9, 2010 at 14:37
  • 4
    By the way, it is not security through obscurity, otherwise you'll also have to call password authentication the same. Security through obscurity is when the implementation is not disclosed. Here, the implementation is clearly stated (it is "I changed the service port"), and the secret ("which port?") is still secret.
    – Juliano
    Oct 9, 2010 at 14:44
  • 5
    @John - actually I see @Juliano's point. It doesn't make the SSH daemon itself intrinsically any less secure, but in the general case running on a non-privileged port does void the normal assumption that root started the daemon. So if you can somehow stop that daemon (e.g. by DoSing it) you can start your own fake daemon in its place without needing a root exploit. That fake daemon might then capture sufficient details to allow further exploits.
    – Alnitak
    Oct 11, 2010 at 8:33
  • 2
    @John, that's true - it still requires the attacker to have gained sufficient access to start a new daemon themselves. The key point is that they no longer need root access to start it.
    – Alnitak
    Oct 11, 2010 at 9:28
21

To really avoid bruteforce attacks, it's always important to follow some steps :

  • Install denyhosts or fail2ban
  • Limit number of connections per second on ssh port
  • Change ssh port
  • Denied root login
  • Enable authentication by key instead of password
Improve this answer
6
  • 11
    Seems like a good list except the port change part that I don't really agree with, that's too much obscurity. A modern port scanner will find it within a few seconds anyway? (and many networks won't let random port traffic out, usually limited to say 22, 80 and 443)
    – Oskar Duveborn
    Nov 14, 2009 at 21:57
  • 1
    The port change limit brute force attacks that checks for ssh running on default port, well if attack is more serious, only in this case attacker can perform a scan of the hole ports in your network/hosts.
    – Ali Mezgani
    Nov 14, 2009 at 22:49
  • 1
    In the fact, i think that behind a good firewall, if you keep your services up to date and if you change the default setting of them, you could be safe from malicious people attacks. and may be not from 0day exploits or unknown attacks
    – Ali Mezgani
    Nov 14, 2009 at 22:59
  • 3
    Using denyhosts/fail2ban mitigates the need to switch ports or require keys. If you don't allow passwords then there's no sense using denyhosts/fail2ban or changing ports.
    – Jeremy L
    Nov 14, 2009 at 23:21
  • 1
    Using denyhosts/fail2ban does not necessarily mitigate the need for additional security measures. The point to security is to create as many road blocks as possible to users who attempt to circumvent the security. Sure you probably don't need to change the port from 22 to 2222 but say another admin comes along and re-enables password... you'll still have several other speed bumps in place. Each step listed above gets the admin a percentage close to the impossibility of 100% security.
    – Patrick R
    Jan 29, 2010 at 14:13
12

I would run ssh on the standard port and use something like fail2ban or denyhosts to limit the number of dictionary attacks.

Another option is to disable login with passwords altogheter and only allow logins with ssh-keys.

Improve this answer
12

Using a nonstandard ssh port would require more explanation and documentation, and answering "I can't log in" emails.

I consider the following benefits of running sshd on a non-standard port more important than the problems it creates:

  • 99.9999% of brute-force attacks are performed by bots which only look for port 22 and never waste any time trying to discover the non-standard port. Brute-force attacks and the counter-measures like denyhosts or fail2ban consume resources, which you will save by simply running the ssh server on a non-standard port.
  • You will get rid of all the useless reports about bots trying to break into your system. If any IP shows up in the failed logins report, chances are that this is a human.

Moreover, if you want to be really nasty, you can always run a fake sshd (with DenyUsers * ) on the standard port 22, while your regular sshd runs on port 54321. This will assure you that all bots and intruder-wannabes will eternally try to login to a service that denies all logins, because noone will ever think of trying to find your real sshd service.

My 2 cents.

Improve this answer
2
  • 1
    This might result in even more support calls though.
    – Brad Gilbert
    Nov 16, 2009 at 15:31
  • 3
    This is true, but enhanced security comes at a price. :)
    – Born To Ride
    Nov 16, 2009 at 15:45
12

Yes it is usefull as it just helps avoid all the brute force attacks and helps keeping the logs clear :)

as for the port number that is up to you, I have seen companies use 1291 fairly often. I use something higher though just to help avoid some of the scripts.

Not allowing root ssh logins and changing the port number and perhaps something like fail2ban and you should be golden. add iptables for good measure and keep you stuff up to date and you should not have any kind of problems.

Improve this answer
3
  • 2
    +1 for "keeping the logs clear"
    – Lekensteyn
    Feb 7, 2011 at 16:21
  • 3
    But look at David Spillett's answer to know why port 1291 (bigger than 1024) might be dangerous.
    – Konerak
    Mar 15, 2011 at 9:57
  • If you're going to advise to use an unprivileged port 2 years after a lot of other, better answers - perhaps prepare a better reason than 'I have seen companies do it'. I have seen companies do lots of things. I rarely want to follow their example.
    – underscore_d
    Sep 29, 2015 at 0:53
11

Doing this for any "security" reason is bogus. It's the best example of security by obscurity which is not security.

If you want to keep your logs a little lighter and cleaner, then yes it's useful as you won't get as many port knocking / script-kiddy bruteforce attempts.

Improve this answer
1
  • 1
    Yep. When I had ssh on port 22, I had >20000 failed password attempts showing up in my logs per day. Which meant I got a security warning email every day. I had password authentication disabled - you had to have a proper private key to login - so I wasn't worried about someone getting in, but I'd rather get security warning emails only when something real was happening.
    – jdege
    Oct 9, 2010 at 13:17
8

Because there are a lot of bad people out there that scan all server IPs for open ports in an attempt to exploit. I used to have hammer attacks on my SSH port all day long until I moved it to another port and on an IP that wasn't linked to any of my websites anymore.

Improve this answer
7

It's useful in that the script-bots which try brute-force password-guessing attacks generally focus on Port 22, so changing the ports usually throws them off. You'll need to balance the value of mitigating that risk with the pain of configuring ssh clients to connect to the non-standard port (not a very big pain if you don't have many users connecting, admittedly).

Alternately, you could mitigate the brute-force risk by turning off password authentication and requiring RSA-key authentication instead.

I don't usually change the port on SSHD, so I can't suggest another number, but check the commonly used ports list to find another number (i.e. one that isn't in use by something else, and thus might be scanned).

Improve this answer
0
6

I always change my SSHd to use port 2222, everyone who would need to get into my servers knows this and it's no secret. There is absolutely no security gain by doing this (unless the would-be hacker is an absolute moron).

The only benefit I get from this is that the auth log doesn't have a million failed login attempts for 'root', 'alice', 'bob', 'sally', 'admin', etc.

Improve this answer
5

Security through obscurity has proven to be useless, usually I configure ssh access with the standard port for all the reasons mentioned above (client problems in reconfiguring, firewall and proxy issues, etc).

In addition to that I always disable root login and password authentication and as last step I use fail2ban to get rid of that annoying messages in the syslog. In Debian/Ubuntu it is as simple as typing aptitude install fail2ban. The default config works pretty well, but I usually tune some parameters to be more restrictive having longer ban time (at least one day) and only 2 failed authentication attempts as trigger for the ban.

Improve this answer
4

I'd say that the thing you're protecting yourself against the most when changing the SSH port are automated scans which will try and gain access using standard usernames/passwords, if your password policies are tight, you shouldn't have to worry about them.

Improve this answer
1
  • not to mention that a port scanner will try other ports too.
    – Jim Deville
    Nov 15, 2009 at 0:27
4

If you disable password logins to your server (which is highly recommended), then changing the SSH port is completely useless. By disabling password logins (and requiring key-based authentication), you remove the possibility of brute-force password attempts, so you're not gaining anything by futzing about with port numbers.

If you continue to allow password base authentication, then you're leaving yourself open to the possibility of a successful brute force attempt or -- more common, in my experience -- your password being compromised because you type it in when using a system running a keylogger.

Improve this answer
4
  • If you s/completely useless/completely useless for security/, I would agree. Changing the port is useful for keeping the noise down in the auth log however.
    – Chris S
    Feb 7, 2011 at 19:58
  • "and requiring key-based authentication" ? what is this
    – dynamic
    Feb 7, 2011 at 20:22
  • 1
    @yes123, SSH can use public-private key pairs to authenticate a user instead of a password. They key pair can also be protected by a password, thus offering two factor authentication (something you know = password; something you have = key file). If you implement this, you can disable password logins (thus someone who knows your local password can't get in with the key file and the key file's password). Passwords are relatively insecure compared to keys, millions of times easier to brute force than key pairs (though still difficult usually). See man ssh-keygen for lots of info.
    – Chris S
    Feb 7, 2011 at 23:49
  • @yes123, the various ssh-related man pages (sshd, sshd_config, ssh, ssh_config) are useful reading. This document looks like a good tutorial on public key authentication with ssh.
    – larsks
    Feb 8, 2011 at 0:25
2

In despite of looking like a typical "security by obscurity", I'd estimate it as having sense since scanning all possible ports (~ 64k) is a way more time costy than just one of them.

But I can add that "port knocking" is much better.

Improve this answer
1

Not an answer but too long for a comment, so I'll make this CW.

I've been thinking about this one for a while and have come to the conclusion that there is a lot of truth in what Juliano says in comments to Alnitak's answer. Nevertheless, I find that by running SSH on port 22 just makes it far too easy to launch attacks of any kind against it.

To solve this problem I do run my internal SSH servers on port 22 and use the firewall to port forward high port to 22 on the target machines. This gives some security through obscurity while retaining the security of a low port, as Juliano has pointed out.

Security through obscurity is not a principle I normally subscribe to and it is often pointed out that a simple port scan will reveal the target port, making the obscurity worthless. To solve that issue my firewalls (Smoothwall Express), both at work and at home, use a script called Guardian Active Response, which is triggered by Snort alerts. From observation I can tell you that when you hit more than 3 different ports from the same source your packets are dropped till the preset reset time. This makes it rather difficult and extremely time consuming to run a port scan, making the obscurity actually worth something. This in fact caused me to get shut out so many times in the past that I've set an exclusion for my source (home or office) IP address. Of course an attacker might stumble on the correct port the first time round but the odds are against it.

Improve this answer
1
  • Good idea with the port forward, John! I think we've both learned something :)
    – Alnitak
    Oct 14, 2010 at 9:54
1

The problem you have is that the firewall is set up to only allow certain IP's to connect, and the boss is tired of opening specific IP's when he's out and about. If you're locking down certain IP's at the firewall, that can be a pain in the arse.

Two things I think of here. Changing the port protects against automated attacks. That's about it, but it's a big part of the average attack traffic out there...automated scripts scanning networks. If you change the default port, those attacks should drop right off to nothing. So it does make sense in that regard. But it does nothing against a directed attack, as the attacker can just scan from Nessus or NMAP to determine what port(s) you're using if you have a special little friend who hates you enough.

Second, if you're using UNIX-like servers, you can install a utility like Denyhosts to stop attacks. If you install denyhosts, it monitors for incorrect login attempts and after (whatever you determine number) failed attempts it will ban the IP for a period of time you specify. Denyhosts can also talk to other denyhost hosts and pass along ban lists, so if an attacker gets locked out of Fred's Linux system in Montana your system will also get that IP for banning. Very useful as long as your users remember their passwords.

It all depends on your usage scenarios. How many programs do you have that are a "pain in the ass" for changing the connection port for SSH/SCP (and if they don't allow it or make it a pain, you really need to consider changing vendors, personally). If it's just a potential fear I'd say it's a non-issue. And this is your boss, asking for something that's not entirely wacky since a lot of sysadmins do flip the SSH port (with some flak from people who hate anything that smells even faintly of security through obscurity...but it really does cut down on cruft background noise from automated scans.)

Boiled down - changing the port blocks automated scripts and most of the bad traffic. Won't stop directed attackers. Consider installing an automated banning utility as well. Security in layers doesn't hurt you if done properly and changing ports helps more than it hurts in most situations.

Improve this answer
1

I've been running SSH on port >1024 for more than 5 years now. Since then, I've not see any portscan attempt in my log file (except from my ownself). There are my servers which I admin that run using port >1024.

Many of the SSH server which run on port >1024, have its own websites which is quite popular.

If the SSH server run in my own company, maybe I've already posted the IP address of that server in here so that you guys can try to hack into the server. Unfortunately the SSH server is not my own. ;-)

But there are other things that you would have to setup in order to make it secure. SSH >1024 alone would not be enough. The port number must not be in the /etc/services, must use port forwarding (e.g. port 1124->22), the direct access to Root must be disable and other thing.

So, if you want to argue, better run SSH on port >1024 for few years.

p/s: 1124 is not my SSH port no. Haha.

Improve this answer
0

i guess if you've yet to discover port knocking its handy, else, no.

Improve this answer
0

Well moving SSH to a different port does make some sense, it helps with security but not enormously. Of course in order to do so you have to have control over your firewalls but that's not an issue for you. What I think undoes the benefit of moving the port is the opening up of accepted range - in fact I'd say that it more than undoes the benefit and exposes you further than you are today. I'm sure you can convince him to both move the port AND significantly reduce the incoming range by collating a list of likely entry points instead of just opening them all up.

Improve this answer
0

Changing your ssh port is a pointless exercise that buys you only limited security. You're better off simply disabling password authentication, which eliminates the risk of brute-force password attempts, and relying exclusively on ssh key-based authentication. If your environment requires password authentication, adopt some two-factor mechanism, like SecurID or Wikid.

Both of these give you a real increase in security, whereas changing the ssh port only gives you the illusion of security.

Improve this answer
0

This is practical POV: I operated publicly visible private ssh servers for more than four years with changed SSH port and I had no single attempt of password scan. For sake of this QA I've just enabled back 22 on one of them for one day. As the result I was scanned approximately every 10 minutes with password attempt frequency around 5 per second. Moreover "scan kiddies" also look for servers with certain OpenSSH vulnerabilities.

For sure this is security by obscurity which doesn't help if you have got enemy.

Improve this answer
-3

It works great, regardless of the whining of the "security through obscurity" crowd.

Silly rabbits, ALL security is security through obscurity. Just because you believe that obscure crypto protocol Z [requiring a combination of DNA samples, shared keys and impossible to actually type by humans passwords] is actually secure doesn't make it so. The truth is, any and all security measure relies on probabilities and assumptions by the users. Too bad for you if I know how to exploit that assumption, but there it is.

Anyway,

We've done this for years, along with a) limiting connection attempts rate (however, i dunno how we set that up, something in the ssh config), and b) a script to ban any host running a dictionary attack with more than X wrong guesses in Y minutes. We ban the host making the connection for a period of time, and that makes it easier to adapt to the topology of changing networks.

If your passwords are sufficiently complex, and they can only make 3 attempts in 15 minutes, there isn't much to fear. It isn't that hard to watch for distributed attacks, either - we usually collate by subnet and ip to rule that kind of thing out.

Finally, all you need is some secret squirrel method to allow connections to your port by modifying f/w rules. It can be anything... smtp, web, magic dns queries. Stuff like SecurID or Wikid just hands over more info to third parties. And don't get me started on secure certificates through third parties.

Improve this answer
3
  • 2
    -1, You don't quite seem to understand what obscurity is... Making something not obvious is not the same as putting a lock on it. While it is true that no security is absolute, there are definitely differences and lumping three-factor authentication in with obscurity doesn't help anyone.
    – Chris S
    Feb 11, 2011 at 20:07
  • 1
    Sorry, Chris, that's cargo cult religion. Maybe you can't pick a lock, and thus think having one makes you secure, but all locks can be picked. Think outside the box: In many cases, making something "not obvious" can be superior to using a lock. Your model/view of security is like leaving your laptop in a locked car with the alarm set - one tweaker with a rock and your laptop is gone. But maybe it's not a tweaker, but someone with a 0-day exploit and time to kill... Oh, look! Chris has a "secure" and quite visible target! Obscurity is a VERY important part of security.
    – random joe
    Feb 14, 2011 at 15:53
  • Sorry but your comparisons and logic just don't hold up. I do know how to pick locks, it's faster to cut them off, break a window, go around. Every security measure has some amount of time and effort required to get around it; obscurity takes small amount of time and effort, in the order of minutes to hours. Real security, like rate limiting password attempts make getting through the password take significant amounts of time. That significant time disparity is the difference between 'fake' security and 'real'; obscurity falls in the former.
    – Chris S
    Feb 23, 2012 at 2:54

Not the answer you're looking for? Browse other questions tagged .