This question already has an answer here:
By default, my SSH client disallows the use of the
diffie-hellman-group-exchange-sha256 key exchange algorithm. However, I need to access a server on 10.0.0.1 that requires the use of that algorithm.
This works fine at the command line:
$ ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha256 email@example.com Password:
However, it fails if I attempt to rely on the following addition at the end of
Host 10.0.0.1 KexAlgorithms diffie-hellman-group-exchange-sha256
Here is the relevant output:
$ ssh -vvv firstname.lastname@example.org debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug3: kex names ok: [email@example.com] ... debug1: /etc/ssh/ssh_config line 72: Applying options for 10.0.0.1 debug3: kex names ok: [diffie-hellman-group-exchange-sha256] ... debug1: Connecting to 10.0.0.1 [10.0.0.1] port 22. debug1: Connection established. ... debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: firstname.lastname@example.org ... debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256 ... debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup hmac-ripemd160 debug1: kex: server->client aes256-ctr hmac-ripemd160 none debug2: mac_setup: setup hmac-ripemd160 debug1: kex: client->server aes256-ctr hmac-ripemd160 none Unable to negotiate a key exchange method
What I find puzzling about this is that SSH is clearly reading the relevant line in
/etc/ssh/ssh_config and seems to be happy with it. But then it tries to negotiate a key exchange with the server using
email@example.com instead of
diffie-hellman-group-exchange-sha256, which of course fails.
Why does it do that, and how can I rectify it?