Technical Tip: SSH key exchange troubleshooting

Markus_M · ‎01-31-2016

Description

This article explains more details on the key exchanges and session negotiation of SSH.

Scope

This concerns especially automated tasks like backing up the FortiGate configuration, troubleshooting as well as implications of related settings.

Solution

In cases where there is a network management server or automation solution to automatically download configurations of the FortiGate (Kiwi CatTools, SSH-scripts, etc.), be careful to not lockout such tools with incompatible key exchange parameters. This of course also applies to normal SSH clients.

The FortiGate offers different settings to influence the exchanged key algorithms which are not always only SSH related but might apply to SSL as well, thus the configuration might not be where it is expected.

For this case, use the packet capture utility in the Network section and filter for the connection from the server on the port configured (for SSH usually port 22).

There should be two packets regarding the key exchange (in short often labeled as “kex”) in which the server sends a proposal, the client would also send another proposal.

Illustration 1: Wireshark example

Example on the server (FortiGate) proposal, taken from a packet capture:

kex_algorithms string: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1...

and for the client proposal:

kex_algorithms string: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

Out of these two lists, the strongest common, overlapping algorithm is chosen.

If no algorithm is overlapping in both proposals, you might see that the client isn’t sending a Key Exchange Init at all.

In that particular case the client might close the connection before sending any proposal since none would match anyways. Logs on both ends should show this as well.

Most default settings should be ok to use, but if needed you can configure the diffie-hellman parameters as follows:

config sys global

set dh-pararms 4096 # this refers to the minimum keylength in bits.

end

A restart of the the SSH server application may be require on the FortiGate for the setting to take effect.
Be aware that the settings here, the keylength, translate to the DH groups seen in the proposal, as well as IPsec proposals and some DH groups would be omitted if the minimum key length would not allow the use of shorter keys.

This is a table of common DH ciphers for reference:

Diffie-hellman groups    -    Modulus (keylength for simplicity)
Diffie-Hellman Group 1   - 768-bit MODP group
Diffie-Hellman Group 2   -    1024-bit MODP group
Diffie-Hellman Group 5   - 1536-bit MODP group
Diffie-Hellman Group 14 -    2048-bit MODP group
Diffie-Hellman Group 15 -    3072-bit MODP group
Diffie-Hellman Group 16 -    4096-bit MODP Group
Diffie-Hellman Group 17 -    6144-bit MODP Group
Diffie-Hellman Group 18 -    8192-bit MODP Group
Diffie-Hellman Group 19 -    256-bit elliptic curve group
Diffie-Hellman Group 20 -    384-bit elliptic curve group
Diffie-Hellman Group 24 -    2048-bit, 256 bit subgroup

If configured as above as keylength 4096, then all DH groups lower than 16 will be skipped and not included in a proposal:

kex_algorithms string: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1

Note: diffie-hellman-group14-sha1 has been omitted here.

Thus, if the client doesn’t proceed connecting to the server, please crosscheck the settings for the client to match the dh-params or lower the dh-params setting (default is 2048).

To debug SSH sessions:

diag debug application sshd -1
diag debug enable

Example of an output with the dh-params set to 4096. Note that the DH group 14 is explicitly skipped:

SSH: Compat: skipping algorithm "diffie-hellman-group14-sha1"
SSH: list_hostkey_types: ssh-rsa,ssh-ed25519
SSH: SSH2_MSG_KEXINIT sent
SSH: SSH2_MSG_KEXINIT received
SSH: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1
SSH: kex_parse_kexinit: ssh-rsa,ssh-ed25519
SSH: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
SSH: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
SSH: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160-etm@ope
SSH: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160-etm@ope
SSH: kex_parse_kexinit: none,zlib@openssh.com
SSH: kex_parse_kexinit: none,zlib@openssh.com
SSH: kex_parse_kexinit:
SSH: kex_parse_kexinit:
SSH: kex_parse_kexinit: first_kex_follows 0
SSH: kex_parse_kexinit: reserved 0
SSH: kex_parse_kexinit: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,
SSH: kex_parse_kexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384
SSH: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
SSH: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
SSH: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
SSH: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
SSH: kex_parse_kexinit: none,zlib@openssh.com,zlib
SSH: kex_parse_kexinit: none,zlib@openssh.com,zlib
SSH: kex_parse_kexinit:
SSH: kex_parse_kexinit:
SSH: kex_parse_kexinit: first_kex_follows 0
SSH: kex_parse_kexinit: reserved 0
SSH: kex: client->server chacha20-poly1305@openssh.com <implicit> none
SSH: kex: server->client chacha20-poly1305@openssh.com <implicit> none

Note: Similar proposal exchanges would be seen for IPsec debugging.

Another setting affecting the key exchanges and used ciphers is the strong-crypto setting:

config sys global

set strong-crypto enable

end

Note: Be aware that this is the default setting and should not be modified, unless the implications are known and acceptable.

In earlier versions of FortiOS, it is possible to find additional ssh related options in regards to the ciphers allowed, also affecting the key exchange:

config sys global

set ssh-cbc-cipher disable
set ssh-hmac-md5 disable

end

Verification.

Verified using Solarwind NMS.

Troubleshooting.

Fixed in the FortiOS version 5.4.1.

Workaround:

Upgrade to 5.4 and run the following commands,

config sys global

set dh-pararms 1024

end

Note: This command is not available on previous versions of FortiOS.

Related articles:
Troubleshooting Tip: SSH error 'No matching host key type found' without any offer.