A particular server I need to interact with has an ancient or crippled sshd inst

Question

A particular server I need to interact with has an ancient or crippled sshd installed, and only supports SHA1 algorithms for key exchange. From information in the Snowden documents, I am leery that keys exchanged with servers with weak key exchange algorithms may be intercepted.

I keep a separate identity that I use with only with this server, and have a specific ~/.ssh/config entry to use that identity when connecting; and my machine-wide ssh_config does not permit the insecure key exchange algorithms.

However, if I have added my regular key to ssh-agent, it appears that my hopefully-more-secure key will still get sent over the potentially insecure key exchange.

Is there some way to further secure my configuration, so that I can prevent a key that I want to keep safe and private from being transmitted with a leaky key exchange algorithm?

If not, should there be? It seems that part of the agent contract is "all of these key exchange algorithms are absolutely 100% secure, so its ok to send any key." Since the key exchange algorithms are not all secure, this is (is it?) a problem.

While key exchange algorithms can be locked down at the machine level, this does not always work in practice, and its pretty easy to accidentally/intentionally override this in per-user config. Is there (or again, should there be) a way to configure "identity XYZ may only be used with KexAlgorithms/Ciphers/MACs?"

Explanation / Answer

You have several misconceptions here.

First, the whole point of a public/private keypair is that you don't send the private key to the server. The only thing your key is used for is signing messages; the server doesn't get your private key at any point during the SSH protocol. Even if you use agent forwarding (which lets you login to other servers from the first one using your key), the server doesn't get your private key: it just passes things on to ssh-agent on your computer, which signs them and sends the signature back to the first server to send on down the line.

Second, "key exchange" in this context doesn't mean "pass around keys," it means "establish a shared secret." The way Diffie-Hellman works is that the client and the server work out a new key, which is completely unrelated to any keys they might have had before. Long-term keys (i.e. the keypairs that are stored in files) are just used to sign elements of the key exchange, so that you know you're talking to the server you think you're talking to.

Third, key exchange in SSH has nothing at all to do with client keys (id_rsa and similar). The server authenticates itself during key exchange using the host key, but client authentication doesn't happen during key exchange. All a client key is used for is to sign a particular string after the key exchange (and after you've sent the username you want to log in to), in order to prove you can sign things with a private key corresponding to an authorized public key for that user. Key exchange algorithms have nothing to do with client keys.

So, weak key exchange doesn't pose any problems at all for private key security. That security doesn't rely on strong key exchange. The only attack you could do is exploit agent forwarding, but that could only work if a) you enabled it in the first place and b) you're still connected (disconnecting = no more agent forwarding).

Fourth, I'm actually not aware of an issue with using SHA-1 for the exchange hash. SHA-1 is weak to collision attacks, which means it's easier than it should be to create two things that hash to the same value. But to successfully MITM the connection, you'd need a second preimage attack, which means creating a collision with something that you don't control. In a collision attack you control both halves of the collision, which is a problem if you're signing something and the attacker can control what you're signing, in which case the attacker could create a colliding pair, get you to sign one thing, and use that as a signature of the other thing. While it's generally better to move away from it, calling it insecure for cases that only need second-preimage resistance is a bit of a stretch.

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.