Why Putting SSH On Another Port is a Good Idea

The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, it will transparently just transmit data between your client and the remote server, irrespective of what that content is. In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.

You can use this to tunnel ssh through an HTTP proxy. Putty supports this out of the box, but if you're using openssh, you'll need corkscrew also.

You can always try to tunnel to an ssh server on port 22, but most proxies will hand you HTTP403 on any CONNECT request to a non-port 443.

More info at http://daniel.haxx.se/docs/sshproxy.html.

You don't get that from it being on 22; you get it from verifying host keys.

You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is bad and therefore we should do nothing.

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.

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.