n3s0 || journal

    Linux & BSD: Configuring & Using OpenSSH Client on Cisco Devices Using Legacy Key Algorithms

    Posted on 4 mins

    Cisco Networking Openssh Linux

    Table of Contents

    Summary

    This is an old thing I came across. But, useful to know all the same. This post discusses some issues with devices such as Cisco routers, switches, etc. where the key exchange algorithms and host key algorithm types are weaker and/or riskier key algorithms. These algorithms are considered legacy options that may need to be specified when connecting to the host.

    Making It Work as Unintended

    If OpenSSH encounters a legacy Host Key or Key Exchange algorithm on the server it’s connecting to. The client will refuse the connection not allowing you to connect to it.

    The Cisco switch I was attempting to login to had only the following key exchange algorithms available. So the OpenSSH client wouldn’t allow me to connect to the device.

    Which is good. We shouldn’t be using legacy SSH key exchange algorithms for ssh sessions unless we have to. In this case I kind of have to. This is a Cisco switch I’m using in my lab and don’t really intend to buy one brand new from Cisco.

    Below is the error output of the switches key exchange offering. Stating that there wasn’t one available.

    Unable to negotiate with 192.168.0.3 port 22: no matching key exchange method found. 

Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

    Connected to the switch using the -o switch and appended diffie-hellman-group1-sha1 as a key exchange algorithm and I was able to login.

    ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@slab-csw-01.lab.home.n3s0

    This can also be added to the users ~/.ssh/config file with the host specified so it isolates these options for this host. The KexAlgorithms appended with the + key exchange algorithm. It will make the key algorithm available for use by the OpenSSH client for the host that’s listed.

    Host slab-csw-01.lab.home.n3s0
	KexAlgorithms +diffie-hellman-group1-sha1

    I have found that there is a side effect to doing so though, based on the output provided below. Looks like the ssh-rsa host key algorithm isn’t found/available either. This is an OpenBSD machine I’m connecting to the switch from and I believe ssh-rsa has been made a legacy option. This probably isn’t necessary on Linux devices though. Haven’t quite tested that yet.

    Unable to negotiate with 192.168.0.3 port 22: no matching host key type found. 

Their offer: ssh-rsa

    Using the HostKeyAlgorithms option and appending the ssh-rsa option to the list of host key algorithms available makes it so I can connect to the switch.

    ssh -oHostKeyAlgorithms=+ssh-rsa user@slab-csw-01.lab.home.n3s0

    This can also be added to the ~/.ssh/config file also. I do this by adding another line. Now I don’t have to add that as another option.

    Host slab-csw-01.lab.home.n3s0
	KexAlgorithms +diffie-hellman-group1-sha1
	HostKeyAlgorithms +ssh-rsa

    There are other key errors that can pop up. I’m just providing this for notation purposes. One bit of advice I can give is to read the errors you’re presented. SSH will provide the information related to the key offering of the remote host.

    Also pay attention to the key exchange and the key type that’s offered so that can be applied to the connection.

    Further Troubleshooting

    Another method for troubleshooting missing key exchange algorithms and host key algorithms is by querying which algorithms are available to the OpenSSH client.

    This one will check the key exchange algorithms available within the OpenSSH client.

    ssh -Q kex

    This one will check for key types available in the OpenSSH client.

    ssh -Q key

    There is another option. One that isn’t necessarily documented in the ssh(1) man page on this Linux box; but is usable in it, I’m writing this post on. But, it’s documented in the actual OpenSSH(1) man page hosted on openssh.org. Sounds like I’ll need to search for it more.

    I’ll provide a link in the references. The -G option can be used to print the configuration after evaluating Host and Match blocks. Pretty useful should there be a need to print what algorithms and key types are being used for a specific host at the time of the connection.

    The command for this can be found below. Just need to replace the host with the device I need to connect to.

    ssh -G user@slab-csw-01.lab.home.n3s0

    Conclusion

    Here went over some notes related to OpenSSH troubleshooting of devices that only offer legacy key exchange algorithms and key types. Hopefully this is useful in the future. Should anyone need resources. They’re in the next section.

    References