How is the security of SSH affected in the presence of a passively monitoring MITM?

Question

In an ideal world, where all links are fully trustworthy from a data integrity point of view, with proper settings, modern SSH can be more or less assumed to be fully secure against eavesdropping on the content of the communications, but may leak metadata (e.g. the fact that you are connecting to a specific host, and some about the usage pattern and amounts of data transferred).

In a somewhat more realistic world, however much we might not want that to be the case, links should be expected to be monitored. We know that encrypted traffic may be specifically retained by powerful adversaries. However, there is still a big difference between passively monitoring traffic on the one hand, and actively tampering with it in-flight on the other.

Assuming that:

• the initial SSH host key is generated by unknown, possibly flawed, means;
• the administrator cannot directly verify the correctness of the SSH host key presented by the server on the first connection, beyond being able to tell whether the login attempt succeeds or fails, but can verify the host key fingerprint via commands within that session once established;
• the administrator quickly replaces the SSH host key with one generated in a trustworthy fashion and reestablishes a connection once the new host key has been loaded;
• the administrator diligently confirms SSH host key fingerprints between the client and the server;
• the administrator does not have access to a distinct channel to the server for key maintenance, so key replacements have to be performed through the SSH session established with the host key that happens to be on the server at the time;
• the attacker does not have access to the SSH private host key on the server, but can monitor, store and later process all communications to and from the server.

In such a scenario,

• what security guarantees can SSH-2 give against eavesdropping on the content of the communications (violation of confidentiality)?
• are these security guarantees any different in the initial connection (before the host key is replaced) and later connections?

Answer 1

I don't know internals of ssh protocol, so my answer is based on general knowledge of cryptography and isn't guaranteed to be right. Well, nothing is.

If the initial ssh key was generated in some "bad" way, then it might be possible or might be impossible for attacker to decrypt your initial connection to the server (it depends on how the session key is generated in ssh - thing that I don't know).

If you regenerate the ssh key on server in a right way and reconnect to the server then, I believe, the eavesdropper wouldn't be able to decrypt anything inside you ssh connection. Since the new key is "good" and the eavesdropper doesn't know it's private part (it wasn't transferred over the network, only it's fingerprint was).

That should be right if the attacker is eavesdropping only. If he can actively tamper with your traffic you have no security guarantees in any of the two cases:

• the initial key was generated "badly"
• admin doesn't know the key fingerprint from trustful source before connecting for the first time

Answer 2

Given your second bullet point,

the administrator cannot directly verify the correctness of the SSH host key presented by the server on the first connection

the administrator can be already connecting to different host (by spoofing DNS or routing the connection to different server), the attacker can be presenting him his own private key (it does not matter which one, since the administrator has no way to find out what is the "correct" one).

The authentication can be very simply redirected to the original host to verify the public key authentication or the password can be simply read (it is transfered in plain text within the end-to-end encrypted SSH session). For example using this modified OpenSSH.

The other commands then can be run on the attacker server (in some sandbox) or somehow transparently forwarded to the real server. This really depends on how the attacker knows this administrator's work flow and wants to misuse it.

##But to the questions:

1.

what security guarantees can SSH-2 give against eavesdropping on the content of the communications (violation of confidentiality)?

In RFC 4251, there is whole section devoted to "Confidentality" of transport layer. There are potential attacks on CBC modes and its mitigation using

"insertion of packets containing SSH_MSG_IGNORE."

This extra packet is send only if

"only if the packet has been sent out onto the network and there are no other packets waiting for transmission."

which makes the network-visible traffic different from what is really going in the session.

The RFC 4253 is explaining how the SSH binary packet is composed. You can notice that the length of the message does not have to always relate to the length of transfered data. There is always padding of random length of random data.

2.

are these security guarantees any different in the initial connection (before the host key is replaced) and later connections?

No. The initial connection is the same as other. But once you write "yes" and you don't know that the fingerprint is correct, you might be connecting to different host and you might not even notice it after authentication.