No, file permissions.

then kill it and serve them?

Users with uid != 0 cannot kill other user's processes.

Or could it even just MITM it?

No, host key verification ensures that you are talking to the intended ssh daemon without packets being intercepted. The host key is a public key of the SSH server, which is verified by the client to be the key registered for that particular host. Since only the server has corresponding private key, the MITM cannot eavesdrop on the key exchange.

(I might be wrong about this, but...) I've seen quite a few instances where SSH refuses to let people even try to log in if there's a chance that a private key has the wrong permissions applied, so as to minimize the risk of someone accidentally letting others read it -- as you suggested.

You'll find the default SSH config on the more noteworthy Linux distributions to do this 90% of the time time without even asking :)

* Note, I guess you could run an sshd that only allows logging in to a single user and runs as that user but both points above still stand even in that case.

I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.

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

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

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.

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

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

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

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.

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.

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

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.

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.

If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea.

(...until, you know, we finally start using DNS service-records for this sort of thing.)

No, that is very, very wrong. This is SOP for an account on a system

nc -l 9000 <- spinning up a daemon on your server

You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there.

Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?

A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.

But maybe I just miss computers where finger, write, wall and talk were all useful commands.

And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)

Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.