4 ms·
It's implied in the examples on this post, but when using public key authentication, an attacker with a stolen SSH host key can pretend to be the server to the
by cesarb 3y ago
It's implied in the examples on this post, but when using public key authentication, an attacker with a stolen SSH host key can pretend to be the server to the client, but cannot pretend to be the client to the server. Which means that the attacker has to pretend to be the server, without being able to see how the server would answer. For instance, if the ssh connection was a "git pull", the attacker has to know enough about the repository state (and about how much of that state the git client has already seen) to avoid complaints from git; if the ssh connection is a shell connection, the attacker has to know enough about the target machine to make the command outputs seem realistic enough for that particular machine; and so on.
And as for "SSH has no forward secrecy", I thought SSH used Diffie-Hellman or similar to derive the session key? The SSH host key (and the client's public key) is for authentication only, stealing them does not reveal anything about past sessions.
- mindslight 3y ago> [the attacker] cannot pretend to be the client to the server Isn't the most common way of identifying ssh clients still just public key authorization? Meaning the attacker can MITM the real client connecting to the server, satisfy the real client's request, and then likely carry on doing whatever it likes. edit: actually no - I can see where my intuition is wrong (out of date from the time of widespread password auth). If the ssh server only accepts input that's been effectively signed by the authentication key, then there's no way for the MITM to send its own requests. Yet another reason to not use password auth.
- progmetaldev 3y agoSSH does have forward secrecy. The OP stated in a previous comment that they have fixed this in the article.