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?"
I have an rsa identity
id_insecure that I want to use with the insecure server, and an ed25519 identity
id_secure that I use by default.
To avoid some potentially weak key exchange algorithms, my
Host * KexAlgorithms email@example.com,diffie-hellman-group-exchange-sha256
To allow access to the insecure server, since they cannot agree on a key exchange algorithm with the above setting, my
Host insecure_server IdentityFile path_to/id_insecure KexAlgorithms diffie-helmann-group14-sha1,and-some-other-icky-sha1-algorithms
However, if I load up
id_secure into my SSH agent, and
ssh -vvv insecure_server, the output will contain
debug1: Offering ED25519 public key: path_to/id_secure debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: ...
My understanding is that I have just sent my
id_secure identity using the diffie-helmann-group14-sha1 key exchange algorithm, which is not as secure as once thought. If I'm mistaken about what is being passed around... I'd also find that to be valuable information.