I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port < 1024.

While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use.

Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).

You actually can sign your host keys (and actually login keys) with relatively recent versions of openssh:

http://blog.habets.pp.se/2011/07/OpenSSH-certificates

That's excellent! Thank you for pointing that out.

> Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL.

I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means.

SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models.

ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.

monkeysphere is how you deal with your SSH keys. It's pretty awesome.

http://web.monkeysphere.info/getting-started-ssh/

So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132

Have a look at SSHFP[1] DNS resource record. If you combine SSHFP record with DNSSEC, you can actually validate the fingerprint.

[1] http://tools.ietf.org/html/rfc4255

You can verify the fingerprint, can't you? Not that I always do it (even is just the "first time", as you said), but IMHO the SSH model is definitely better than a central authority you have to pay to get your certificate signed.

They just need to scan once to find the port speaking SSH, then brute force as usual.

If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.

OTOH, not running on port 22 prevents you from drive by scans.

You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by.

Having port 22 open can end my IPs on a list of "let's try to break later".

It's not close to a complete solution, but I find it beneficial.

Ideally, you can run both https:// and ssh:// on 443, with sslh.

Everyone who's expecting to see HTTPS will see it on :443 as well.

I can recommend gatling by passing firewalls on port 443. It waits 2 seconds for a HTTPS request before it starts OpenSSHd in inetd mode.

I would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time.

The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.

I run ssh in a non standar port and its annoying to always specify the port. Thank you for the tip about ~/.ssh/config

I think this is the easiest you can/should do that helps keep random checks and break-in attempts away.