Security and Obscurity: Does Changing Your SSH Port Lower Your Risk?

I agree wholeheartedly; it’s just another level of protection as part of defence in depth – although I’d use port 48351, or similar, rather than port 24!

This action would only be security through obscurity if you had no password or private key on the accounts – the non-standard port was your only protection. I’m sure that that is not the case!

A further protection is, on your firewall, to only permit connections with a source port less than 1024, then use the ‘UsePrivilegedPort yes’ in your ~/.ssh/config file to tell ssh to use source ports < 1024. My quick checks with nmap showed that nmap used source ports over 1024 – so even a hit on the right destination port would not result in an ‘open’.

Were you monitoring the traffic to your ssh ports, if yes, were most of the source ports < 1024??

The problem with changing ports that services listen on is the loss of trust. Services that listen on ports lower than 1024 are considered “trusted” because they require root privileges. So if SSH is enabled on a very high port, I’d be worried about my personal security when I connect to that system.

Also, using service detection with tools like NMAP will quickly remove negate any extra security that is provided by running on non-standard ports.

The only upside to running on non-standard ports is that automated attacks won’t occur, but honestly a good firewall ruleset or a something like deny_hosts really solves the problem while retaining the “trust” factor.

plz can you tell me how to change the port of the ssh on fedora 8 because ive 2 servers on the same router when so i cant login to one of them because the servers ssh have the same port plz help me , thx

What you’re advocating here is not so much security improvement through obscurity, but security improvement through irregularity. You could proclaim from the mountaintops that you serve ssh on port 24—in fact, you just did—and it would still have improved your security. Heck, you could respond to attempts on 22 with a message redirecting them two ports higher, and it would improve your security, because it would still filter out all the wardialer-style scripts. It wouldn’t work if everyone did the same thing, but by decreasing regularity, you make it much harder for the scripts to account for your case. None of these stop someone determined to get into your system in particular, of course, but that’s why you’re not relying on them.

I just run SSH on a non-standard port >1024 to keep down the size of my log files.

i used to do this, but switched to using knockd instead.

one reason i switched is that it wasn’t always easy to persuade other software to use the new port. even sftp requires quite an ugly syntax to pass the parameter down to the ssh layer.

the other reason was that my isp started “traffic shaping”. that means that data transfer using non-standard ports had limited bandwidth.

neither of those is a very powerful argument (and i’ve since changed providers – from vtr to telefonica chile – to avoid the traffic shaping) and knockd is itself a bit frustrating to use if you don’t have the client handy (you can trigger it using telnet, but it’s hit and miss).

even so, you might consider it… http://www.portknocking.org/

ps also, of course, it can protect other protocols too.

I do this too. A while back I got really annoyed by the number of brute force attempts on my servers.

I have a HIDS system in place which alerts me to brute force attacks. On port 22 I would get at least 10 messages that it had blocked a brute force attack every day. I thought about disabling that rule, but then I realized that what I wanted to do was block out the annoying scripts, not the deliberate attacks on my systems. So I moved the SSH port to 831 (just made the number up). Now I don’t get the attack messages unless someone scans my system to look at open ports and attack the services on them, something which indicates a much more dedicated attack which I might actually be worried about. I think I’ve gotten all of one ssh brute force alert across 10 servers.

To mitigate the inconvenience I just put the ports in my .ssh/config file along with shorthands, such as:

Host s1 HostName server1 Port 831

Really quite elegant.

This is a really, really good idea. Security through obscurity is not a replacement for other standard industry-best security practices, but it is a very helpful part.

The bottom line is it consumes server resources to deal with bogus connections. Even if you have an effective rejection system in place, a non-standard port reduces the amount of traffic you have to deal with.

I switched mine back to port 22 for 24 hours and (using a specially compiled version of SSH) recorded what usernames/passwords the bot is trying.

If anyone wants the list email me.

Just add another port to the Port line in your sshd conf file.

sftp respects ~/.ssh/config; you only have to put the non-standard port in that file, and ssh, sftp, etc will use it.

man ssh_config.

It would be interesting if you try your experiment again but instead of having the two ports open simply move the port to 24. I am wondering how many scripts first try port 22 and then move on to try other ports. This is probably reducing your counts a bit.

From my own personal experience, I have no seen a difference in switching ports. I have to connect from hotels quite frequently. Obviously someone makes their living from hacking there, because when I get home I am still seeing attack on the port I selected for that week. If you just open the port, most automated attacks will use the default. If you are scanned and have banners, they will figure it out if they want. My guess is since they saw the traffic going to the particular receiver socket, they recorded it then performed their attack. In your experiment, how many connections were you making to port 24 from the public? Besides the minor annoyance of the attacker opening connections, and I had high hopes they were not going to crack my key and password.