Hacker News new | ask | show | jobs
by pepr 4616 days ago
His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client that the server key doesn't match.
1 comments
dave1010uk 4616 days ago
Could a non root user just read the host keys from sshd, then kill it and serve them? Or could it even just MITM it?
link
microtonal 4616 days ago
Could a non root user just read the host keys from sshd,

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.

link
xarball 4616 days ago
That's what file system permissions are for, on the private key.

(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 :)

link
entropy_ 4616 days ago
No, they couldn't. sshd usually runs as root* so it can create shells for in user that's logging in. Therefore, only root could kill the daemon. Also, as mentioned by the sibling post, its configuration files are usually(if not you have a serious problem) only writeable by root so nobody else could modify them.

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

link