Privileged ports are why I disagree with this rebuttal. I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.
You don't get that from it being on 22; you get it from verifying host keys.
You know how you just wrote a blog post talking about how more layers of security are better even if all you're gaining is obscurity? This isn't an exception. And it is a valid point that by moving from a privileged port to a non-privileged port, you just traded away a layer (arguably a more useful one than you gain by moving away from 22) for absolutely no reason. (You could move to a different privileged port and still get everything else.)
tl;dr: You advocate giving up an actual layer of protection for a layer of obscurity. This is especially puzzling when you could get both.
Further, the reality of the situation is that as a practical matter most sysadmins are terrible about key management and when they see those warnings the very next thing they almost always do is immediately delete the key and hastily attempt to login to the machine via ssh. (The better ones to see what's going on and try and fix it, and the worse ones just assume that the key changed because sysadmins change keys all too often without notifying users and don't investigate at all.)
It turns out that humans are annoyingly predictable.
I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024.
I could go for that.
Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about not being a target at all.
As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#T...
Honestly, the only win of a using "privileged ports" these days is you don't have to worry about the odds of some other service randomly binding to your port. Since most systems spin up ssh well before they spin up services that bind to random ports, and generally don't ever shut down ssh, that isn't much a win, but either way, it is NOT a _security_ win.
You might be surprised how often StrictHostKeyChecking is no. Are you checking it on your active installs?
But I agree, the privileged ports point isn't something that should be brushed aside.
ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour.
galacticdominator% sysctl net.inet.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023
Read the article.
Seems like something a little script or patch could fix up really easily - make sure your daemon is running on port 1234. If it's not, take whatever defensive measures you think would be effective.
If you're worried about an impostor sshd on that host then I would tend to agree that it's simply not prudent to be connecting to that server at all, let alone passing key material or credentials.
If you have fear that a port of your server listens on any unprivileged port and it than you have far more problems with that box then the sshd. _If_ a port is opened by a user that emulates the sshd daemon to grab your passwords that means that:
a) this is the usual port you use for ssh
b) your box is hacked, then the real sshd daemon that usualy would listen at this high port is replaced by something else. That means sombody has root access to that box (the sshd has to be killed for that)- big big OUTCH
c) you box isn't hacked but you have some non trustwoth people have access to that box, that use some exploits for rights traversal
All in all I would say, constructing a security issue of using a non standard ssh port is academic. If that could be abused you have far more problems on your system than that changed ssh port.
On our production servers I use the following:
1. ssh access with keywords is disabled 2. ssh access for root is not allowed 3. ssh access is allowed from one trusted IP address only 4. restrict users with access to ssh to only the needed ones 5. users with git access get as shell '/usr/bin/git-shell'
optional: If you're paranoic like me and like some technical baublery you step 3 this way that users have a VPN to the server with the trusted IP
If you run ssh on a static port, then it really does not matter whether it is 22 or 2200, as long as it remains static, and everyone knows the correct port.
If it turns out that that daemon is logging your passwords, then someone has already compromised your host.