Hacker News new | past | comments | ask | show | jobs | submit login
Why putting SSH on another port than 22 is bad idea (adayinthelifeof.nl)
26 points by justinwr on Oct 26, 2013 | hide | past | web | favorite | 61 comments

Security through obscurity is useless. I have heard people repeat this for the last 20 years. They are wrong and they have no idea what they are talking about. They just parrot what others say. Like chaos it perpetuates itself.

We camouflage tanks. We build stealth fighters. If obscurity had zero value, we'd just paint the tanks bright pink with hot orange flames and drop all the stealth research too. No need to sneak around. Obscurity is useless right?

Hide from the bear and it might not find and eat you. Move your ssh port and your logs will have less idiots out there filling them up. That fact alone is worth changing ports.

Obscurity has its place along side other tactics. And when you put it all together, you'll have a more secure system.

So please cut the "Security through obscurity" crap.

Hell, passwords and keys are just obscure strings.

Security through obscurity is only a problem if it's the only security.

Right, adding obscurity doesn't decrease security. It might help... worst case it does nothing.

It might actually decrease security, as it gives a false sense of security and people just take it as their only security measure in the end. Give them obscurity and they feel secure. There are countless examples of this, I don't believe I need to give some here.

What are some examples? Like hiding a wallet in a shoe at the beach? Even that is actually successful in some cases.

Most thieves aren't career criminals in search of wallets. Perhaps a respectable working man sees a wallet of a young rich kid currently in the water. The man could use some extra cash and sees large bills protruding from the wallet and decides to take it. Why not? The man has a family and that kid probably has a trust fund.

The wallet stuffed in a shoe or buried under a towel prevents temptation. It's not actually more secure but it keeps honest people honest.

Nothing is really secure. Adding security is all about making something harder. Harder to live with, harder to access, harder to do un-detected, etc. If hiding something from plain sight makes it even slightly more troublesome of a heist, it's actually security IMO.

It shouldn't be your only form of security but to write it off completely seems silly.

Now imagine a million people from all over the world passing by. Would hiding the wallet in the shoe help?

I agree. Changing the port or hiding with port knocking is useful especially for keeping logs clean.

Generally, I think it's best to avoid publicly accessible SSH but if needed, changing the port is a good idea.

I always remove password auth and direct root login however even though my machine is now secure, the logs are filled with failed login attempts.

Clean and tidy logs help spot anomalies indicative of real attacks and not someone looking for open port 22 and hoping the combo root/root somehow works.

I don't think it's wise to change the port and consider things safe. All other security advice still applies however changing the default port in addition to locking down access seems like a wise decision to me.

I think you're misunderstanding where that came from, or what it means.

The idea behind security through obscurity being bad isn't about stealthiness, it's about that the idea that an attacker not privy to details of the system isn't really disadvantaged. Using a secret custom cipher is worse than using publicly vetted and analyzed ciphers like AES or ChaCha20.

Specifically, port-knocking isn't about security through obscurity. Your secret is the knocking sequence. Making the port inaccessible without that makes sense.

> We camouflage tanks. We build stealth fighters.

A lot of the army forces are wearing camo fatigues 100% of the time while in combat zones, I'm sure they would have a lot to learn from you.

Sarcasm aside, security through obscurity is not very useful when it's the only defense vector used but it's very important when it's part of a multi-angle defense. The more hurdles you put on the path of hackers, the more time you buy to defend against them.

Thank you. Everytime I hear someone say that I cringe. So sick of hearing it. It's useful, just not the only thing you should be doing.

this is so true... like if you use port knocking, how can that not increase security

> When we start SSH on port 22, we know for a fact that this is done by root. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords.

Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern? The root user probably told me what the SSH port is. If I don't, then well what's to say the SSH daemon on port 22 is secure? In any case, there are many other ports that are not 22 and are < 1024. You don't have to pick 2222.

Changing the port is not the ultimate defense against attack, but in my experience it does reduce random drive-by type attacks. Same reason you raise your windows when you lock your car - as easy as it is to break a car window, a thief would rather steal from a car with an open window than smash your windows and steal from yours.

>Well OP is assuming that I trust the root user of the machine I am SSH'ing to. If I do, then what's the concern?

Trusting the root user is different from trusting everyone with shell access to that machine. Only root (or a process with the appropriate capability) can bind to port 22 because it's below port 1024. Normal users can bind to port 2222. So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon.

This is mostly mitigated by the fact that $EVIL_USER can't read the host private keys which means that the impersonation will be detected by anyone who has the host in the known_hosts file, but that only counts for ssh, and assumes you've connected to the host previously. If you're running something like DNS or FTP on a multi-user machine, using a non-privileged port is a Bad Idea.

> So now $EVIL_USER puts "@reboot /home/$EVIL_USER/bind_port_2222" in his crontab, or some such other method of getting to port 2222 before the ssh daemon.

I hadn't thought of this. Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct?

(Once the SSH daemon has bound to its assigned port, then I don't think the port matters - if the user is able to kill a root-owned SSH daemon, he's likely able to start his service on whatever port he wants).

> Setting up the malicious executable to somehow bind to the SSH port before the SSH daemon is able to and then rebooting the computer - assuming the user has reboot privileges - seems to be the only way to do this correct?

Not necessarily. You wouldn't necessarily need reboot privileges, you could just wait until root reboots the machine for whatever unrelated reason (e.g. kernel update). And you could do the same thing with the daemon: Wait until some updated version of the daemon is released and when root is installing it there will be a race starting when the old version exits before the new version starts and binds the port.

You're also just causing trouble for yourself because then you have to worry about a bunch of arcana like whether the daemon is using SO_REUSEADDR, IPV6_V6ONLY, only binding to the IPv4 address when the machine is dual stack, etc.

If you don't trust the other side, you aren't administering the server, in which case this article isn't written for you.

If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22.

There are much better solutions to dealing with drive-by attempted logins, and some of them are built into ssh.

There are plenty of unassigned ports below 1024 that you could happily use without theoretically stepping on toes, why not use one of them? Further down the page there are several people stating tangible benefits for moving off port 22.

I said above 1024 and picking on other than 22 is just Security Through Obscurity. I can banner grab you in less than a second and figure out which port is running an ssh server. If you really want to then go for it. But above 1024 is a no go.

> If you are, then the author is 100% correct that it is not a good idea to run a SSH server above port 1024, or any port other than 22.

Ok, but you haven't explained why. The author's stated claim is that running an SSH server over 1024 means the connecting party cannot trust the server, but that of course doesn't apply if you are running the server.

If you want to truly secure your server, then yeah, changing the port doesn't really do much but there are some minor benefits (see other responses in this thread, and on the internet). I'm still not seeing the harm.

Put another way, if someone has gained access to run a script as a non-root user on my server, and somehow managed to kill SSH which is running as root to bind to that port, gained access to my host key (which should only be readable by root), so that my ssh client won't warn me when I connect, and is now running an ssh-alike on that port, I'm pretty well owned already. It's hard to see how someone with this much access doesn't have enough to go ahead an run their ssh-alike on port 22.

That said, I run ssh on a non-standard port for one reason only, it's a crap-load easier to check the log files for suspicious activity that way. I still run use the same protections I do for servers with ssh on 22.

If you are running the server and your server is compromised than the attacker can remove the ssh server you are running and put up his own malicious program to collect your password if and only if they port is above 1024, and they don't need root privileges, they can have www-data privileges or whatever

Again if he can remove ssh running as root on port 1xxxx, he can run his ssh-alike on port 22.

but he can do 1xxx from an unprivileged NOT ROOT and he requires root to do that with port 22, again

So basically, he's gained root once to kill ssh running as root, but you think that gaining root again in order to run something on port 22 is what's going to stop him?

What OP points out is good for starters but If you were really serious about security, you'd be locking your servers behind VPN and 2 factor auths. Cloudpassage.com does a pretty good job for locking down your servers for truly serious.

> capture your passwords

With public key auth, an attacker can't capture anything useful (unless of course they record traffic and later figure out a way to later capture the private key [1], but this isn't a problem that changing the port will fix).

> mimics SSH

You can't mimic the key files in /etc/ssh/ssh_host_whatever_key without root privileges, assuming these files are properly secured. So users will get an unexpected warning that the host key has changed.

> simple script that listens to port 2222

True -- in cases where something isn't already listening on 2222. But if sshd is started early in the boot process and listens on 2222, won't any script started as a regular user be unable to bind to the socket?

[1] https://news.ycombinator.com/item?id=6609601

Also, what if ssh is on port 1023, which is still a non standard port, not default but privileged, does this help in any way?

I'm asking because I don't really know but have to set up my own servers from time to time (hobby admin).

Edit: I always use key based auth, don't allow root etc.

It cleans up your log files, that's why I do it. If you run ssh on port 22 your log files with be full of script kiddies with turnkey exploits spamming every IP address they can find. Change the port and suddenly that the logs get much, much quieter. So it's not really a security technique, it's a convenience technique.

I can't say for sure it would help in any useful way, but it won't reduce your security to run ssh on port 1023.

> So running SSH on a non-privileged port makes it potentially LESS secure, not MORE. You have no way of knowing if you are talking to the real SSH server or not.

Of course you do: the SSH host keys. They are an integral part of the SSH trust model. If you blindly accept any host key thrown at you, for a machine you didn't just boot for the first time, then nothing can help you as you can easily be man-in-the-middled even if you are using port 22 (say from the cafe wireless you are using).

So many problems with this article, it's very hard to take seriously. Let's start with not giving us reasons to protect the innocent. Oooh. Scary! He must be a real pro at security! He's keeping secrets that are too valuable to share! Please.

Next, he talks about anyone setting up a script to listen on a non privileged port to collect passwords. Okay. So, are you saying I shouldn't connect to your server then? Because if I set MY server's SSH port on 2222, I'm not worried about anyone collecting passwords on MY server. Unless they have root. Then I have bigger problems, and they can also collect my password when logging on to port 22.

Also, security through obscurity is hardly useless. Sure, don't use it as your only security defense, but it does have value. Obscurity means hiding something of value from plain sight. Can you find that object? Sure. That doesn't mean stealth is pointless. If so, we wouldn't have camouflage, stealth bombers, and the NSA. Stealth can be be valuable.

Lastly is keys over passwords. Again, unless you have root on the box, you're not getting the login password without brute force, or some protocol vulnerability. And, if your password is weak, what makes you think using keys is any stronger? First, you can create SSH keys without encrypting it with a password. If you choose to encrypt it with a password, what makes you think that password will be any stronger? Sure, remote password brute forcing us infeasible, but scanning Github for private keys isn't. What's one server versus another, unless you're targeting the user?

No, this article isn't thought through.

I put SSH on a different port because it cuts down on the drive by login attempts. I don't have random users on my systems so I don't care that it's possible for non-priveleged users to listen on high ports, there shouldn't be anything listening on any port on my systems without my knowing about it. And I don't use running ssh on a different port as an excuse for lax security.

Under different circumstances different tradeoffs would apply, but for my current modes of use I don't see a compelling reason to put SSH on port 22.

This has been my general theorycraft as well. It's still on a privileged port but not standard. I'm curios as to if it has any effect though or if it's all pointless.

If you are using passwords for auth with SSH you have already lost.

This raises a few questions.

firstly, How does he hope to mimic SSH with a script, when most 'companies' will roll out DNS sshfp records, heck, I even do it at home. -- he'd need to access the private keys in /etc/ssh/ to be able to do anything; unless he's rooted my box, I don't see how he could.

Secondly; he'd need to kill my sshd process in order to make his script work, sshd is not the kind of process driven behemoth that apache+modphp is, so you can't brute force it to death- how are you going to kill it if you're not root?

Finally; if you kill my sshd- where does your session go.

of course, all of this could be bypassed if you had root, but if you are root you can do anything anyway- you could capture and decrypt data with the private keys- surely that'd be easier.

(also, if you're root you can bind port 22 anyway, so it's a moot point)

I run SSH on a non-standard port because it makes it easier to see when someone is genuinely targetting me for attack. If I run SSH on 22 then I won't know when someone is targetting me for attack since I'll be under constant script kiddie attacks from everywhere all at once. If I have nothing on 22 then all those attacks just get silently blackholed. Which is ideal.

The non root user issue is invalid. While I can start an ssh-like service on port 2222 as a non root user, I cannot read the private ssh server key owned by root. If the sshd got switched to one run by an unprivileged attacker, you would get a bad server fingerprint and not connect (you wouldn't, right?).

Here's my response to this, point by point:


I'm not sure your comment about the ability of a user to create a daemon on another port being the same regardless is correct:

> He claims that you shouldn’t run your SSH daemon on a non-privileged port because anyone can spin up a daemon up there. Great point, except you can still do that even if you run your main one on 22.

... surely the point here is that this is not an internal server (if it were, you wouldn't be getting tens of thousands of attacks in your example).

So in the case of a server running on port 22, someone with user level access couldn't set up a daemon running on port 2222 because it wouldn't be allowed through the external firewall. Put ssh on 2222, and you just opened the firewall for a port any user can open.

I agree with a lot of your other comments, though.

Security through obscurity is not to be avoided outright, using only security through obscurity is to be avoided outright. If you have an otherwise secure system and then you obscure it in some ways, the worst that can happen is that it has no effect. So the problem is in thinking it alone will protect you, but it is not harmful in itself.

I think people throw this phrase out because it scans nicely and makes you sound like you know what you're talking about, especially to yourself.

I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords.

ignoring other authentication methods, PKI, etc..

Obscurity is only a poor security layer if it's used as a substitute for security instead of a supplement.


Camouflage on tanks doesn't remove the armor; it just lowers the chance that it'll be needed.

Running ssh on another port is typically something you do with your own machines. If you're connecting to a foreign system, you either trust it or you don't. The fact that ssh is on port 22 or not means nothing.

a) Nobody doing this expects that it will increase the difficulty of cracking the server via SSH, or at least nobody I've talked to does it for this reason and I certainly don't. b) Since when is the uid that started a process a form of authentication? c) Who cares what the default settings are for most SSH clients? It's trivial to put it in your config file and forget about it. d) Using port 443 for SSH is a legitimate use to get around firewalls/traffic shapers.

Pretty sure I'll continue to put SSH on a non-standard port. I already monitor my systems and its their logs heavily, and this cuts down on 99% of SSH-related spam. Any attack that's serious, the port will not matter.

obscurity is not security. nothing's going to stop people from portscanning your server no matter what port it is on.

Stop trying to make it so cut-and-dry. This is not pure cryptography where the adage actually applies (a cryptographic construction should remain secure if everything about it except the key is known.)

You shouldn't mistake obscurity for security, but obscurity that doesn't actively bother the user doesn't hurt security. Again, emphasis on not mistaking obscurity for security, i.e. moving SSH to a port other than 22 does not mean that you can keep using password authentication.

Virtually all DNS servers on the Internet deny zone transfers (AXFR). This is entirely an "obscurity" measure, but it's still useful as long as people don't assume one of their hosts won't be found if it has a guessable hostname or IP address. There are many other examples.

I don't see what moving it to 2222 does that turning off password authentication, requiring public key authentication disallowing remote root login, and fail2banning repeated login attempts doesn't.. Is there a vulnerability in SSH or our asymmetric key cryptography that I don't know about(other than the one possibly introduced to the random number generator)? If there is, is the NSA less likely to use 2222 to knock on our door than 22? The only thing - the only thing - that moving it to 2222 does is reduce load avg due to brute force botnet attacks. And banning ips after 3 failed connection attempts should have a similar effect on the load avg. That is the only benefit. If you ask me that benefit isn't enough for me to give up the time spent typing -p 2222 every time i run the ssh command.

Even if that's the only thing, that's not useless. Just don't mistake it for a security measure.

Also, you can put port numbers in your SSH config, so you never have to type them.

I move from computer to computer a lot and don't take my SSH config with me. Typing the extra -p 2222 is tedious when it doesn't give me any benefit.

The only thing moving the SSH daemon does is give us a slight, conditional performance benefit (that using fail2ban on port 22 also gives, along with an actual security benefit). It does not give us any security benefit at all.

Good rebuttal. Maybe we should start downvoting so that this truism that constantly gets trotted out can go away.

On the other hand, your explanation plus the other replies probably help people dispel this notion for others, so maybe it's good to keep this kind of thing coming around.

It gets trotted out for a reason - because it is true.

All the change of port does is reduce the load avg from brute force attacks and failed connection attempts. You can accomplish the same thing with a fail2ban rule on the standard port.

Changing the port doesn't prevent intrusions. That's not a security benefit. That's a performance benefit, and a short-lived one at that, since what do you think botnet hackers will do once they've figured out that we're all running SSHd on a non-standard port and their brute force success rate goes to zero? They're going to adapt to the situation and scan the machine before connecting to it.

It's not security if it doesn't give a guarantee. Changing the port guarantees nothing.

You're right that it doesn't prevent intrusions from someone who's focusing on your machine, but doing something unusual that requires extra steps of attackers does usually decrease the likelihood of intrusions, especially from automated means. You're acting like bots frequently portscan when trying to brute force ssh, and I can tell you that they generally don't.

I typically don't bother, and just use fail2ban, but it's silly to say that it doesn't make it more secure. It does, if only marginally. As long as people are aware that it isn't sufficient, and that they still need to use strong passwords and/or public key auth, then there's no problem with saying that this makes things more secure.

I like to run hardened SSH servers - key only authentication and specific lists of permitted users. From a security point of view this works on the default port or an alternate port. Root is blocked from logging in directly.

Having SSH moved to an alternate port helps mitigate the load caused by continuous SSH worm connections. Having the firewall additionally block SSH except from pre-approved adds additional defense, but adds the complexity that the admin cannot login from his mobile phone using just SSH without first adding his current temporary IP address to the firewall.

The alternate port, is not by itself a security mechanism but it can help in real life deployments.

It is a good article and raises really good points. I have bookmarked it because I do want to experiment with the author's iptables example.

Moving to a different port keeps the server logs a lot cleaner, making real attacks easier to spot.

Moving ssh to a different port and using something like port-sentry could make it much harder. It will not increase your security per se, but it can make you less vulnerable to zero day exploits against random general internet scans.

What percentage of attackers port scan a broad range of ports vs. just trying port 22?

I have not measured it in a long time, but the effect of blocking port 22 and leaving open a non-standard SSH port is dramatic! As in noticeable decrease in load average on the server.

Yeah, its not about increasing security against an individual but pretending to be a less appealing target to the masses.

Ah but what about Port Knocking?


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact