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.<p>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?<p>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.<p>Obscurity has its place along side other tactics. And when you put it all together, you'll have a more secure system.<p>So please cut the "Security through obscurity" crap.
> 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.<p>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.<p>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.
> capture your passwords<p>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).<p>> mimics SSH<p>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.<p>> simple script that listens to port 2222<p>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?<p>[1] <a href="https://news.ycombinator.com/item?id=6609601" rel="nofollow">https://news.ycombinator.com/item?id=6609601</a>
> 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.<p>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 <i>even if</i> 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.<p>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.<p>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.<p>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?<p>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.<p>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 raises a few questions.<p>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.<p>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?<p>Finally; if you kill my sshd- where does your session go.<p>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.<p>(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:<p><a href="http://www.danielmiessler.com/blog/putting-ssh-another-port-good-idea" rel="nofollow">http://www.danielmiessler.com/blog/putting-ssh-another-port-...</a>
Security through obscurity is not to be avoided outright, using <i>only</i> 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.<p>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>I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords.</i><p>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.<p><a href="http://www.danielmiessler.com/blog/putting-ssh-another-port-good-idea" rel="nofollow">http://www.danielmiessler.com/blog/putting-ssh-another-port-...</a><p>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.