I've noticed that a lot of admins change the default ssh port.
Is there any rational reason to do so?
I've noticed that a lot of admins change the default ssh port.
Is there any rational reason to do so?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
This question came from our site for professional and enthusiast programmers.
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.
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.
To really avoid bruteforce attacks, it's always important to follow some steps :
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.
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:
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
i guess if you've yet to discover port knocking its handy, else, no.
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.
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.
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.
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.
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.