> 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 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.

Ok, fair point.

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.

Firstly, I like the tone you used to concede your original point.

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?

For 90332, I suspect not many :)

Highest port number is limited by the port field in TCP[1]; a unsigned short (2^16, 0-65535).

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#T...

Privileged ports isn't an example of security through security. Maybe you could call it security by convention. Still, it relies on a number of assumptions, none of which can be relied upon if a system is compromised, and if the system isn't compromised... well, you don't have a problem now do you?

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 get it from verifying host keys.

You might be surprised how often StrictHostKeyChecking is no. Are you checking it on your active installs?

To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. Many of the lower numbered even-numbered ones are good options as for historical reasons those are all mostly unassigned. (Pretty much any even number below 16 isn't used by much.)

But I agree, the privileged ports point isn't something that should be brushed aside.

> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22.

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

What can go wrong by changing the listening port of sshd? I have changed the port on my vps purely for less clutter in my logs, but I haven't had anything go wrong because of it.

When you have to use the java applet of the Control Panel in your browser to manage your VPS. If your sshd is not on port 22, typically the applet won't find it and you're screwed.

It introduces a communications problem. Which machines are running SSH on a non-standard port and what is it? Plus some tools are harder to set up, IIRC SVN+SSH is one of them.

> What can go wrong by changing the listening port of sshd?

Read the article.

The absolute best way to know that is to know the public host key and verify your keys. Additionally, you don't have to resort to high ports to achieve a best of breed. Just !=22 is enough to avoid majority of skiddies.

How can you ever tell that by port alone? If a box has been exploited, it's been exploited.

Exploiting a single user's account and opening a high port is not the same as getting root on a system.

So you're operating with a compromised user account capable of killing your sshd on port 1234 but there's no other local escalation exploits?

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.

Look at it a different way. If a bug was found that could kill sshd, then a local user could replace it.

Anything connecting to this replacement sshd would immediately be spotted as fraudulent due to keys.

Or instead of doing a script or a patch, you could just do the right thing in the first place and run your daemon on any of the literally over one thousand ports set aside for privileged services.

Running on a privileged port doesn't change which other hosts can connect to the privileged server though. At best it tells the client that the server is probably running as root (or has the appropriate capability bit).

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.

What makes you sure, that the daemon listening on port 22 is is a 'true and sanctioned sshd'? Because of it uses a port under 22?

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

How are you going to log in to your shell, with your environment, without a daemon that has the suid bit? A user can never install such an sshd without having root permissions at some point.

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.

Then bind to another port under 1024, so it's privileged, but not port 22.