The SG300 and SG200 series of Cisco Small Business Ethernet switches come up often as switching options for lab environments. Both options are managed switches with upgradable firmware and bootcode images. Hopefully this public reminder to myself on upgrading the firmware will help someone else.
When performing firmware upgrades on these switches you have three options for transferring new firmware and boot images to the switch: HTTP/HTTPS, TFTP, and SCP. HTTP/HTTPS isn’t available for upgrading Boot Code, thus I quickly eliminated this option. TFTP is a popular choice for these types of operations in the networking world. Chris Wahl covers this process well on this “Hands On With a Cisco SG300-52 Switch” post. I’ve setup TFTP servers a time or two in the past, and could have done so again. However, I already had several Linux VMs up and running with SSH servers supporting SCP and decided to use that.
The interface to perform this upgrades is fairly straight forward and involves entering: one time use credentials, the type of file you want to transfer, server address, and the file path. However, in my experience with Debian and Ubuntu based Linux installs, attempting this out of the box results in a less than insightful error “scp: Connection closed by host.” You may find similar behavior using other distributions of Linux or other platforms entirely, using the solution described below may require you to adjust file paths or names as used below.
However, on the Linux host you can find some more helpful information. Looking in /var/log/auth.log will hopefully lead you to one of two types of errors (for both of these messages I omitted the timestamp and hostname):
sshd[1241]: fatal: no matching cipher found: client aes128-cbc,3des-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com [preauth]
or
sshd[960]: fatal: Unable to negotiate a key exchange method [preauth]
On the most recent firmware release I’ve been unable to recreate the matching cipher message, after having seen it during two prior firmware updates.
Fixing either of these messages is as simple as adding compatible cipher and/or key exchange protocols to your sshd_config. You can find the supported algorithms for the switch in the Administration Guide, for example page 518 of https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/Cisco_300Sx_v1_4_AG.pdf. You may be able to find the supported and/or default algorithms for your Linux distribution via distribution documentation, for example, Debian’s manpage for sshd_config lists both the supported and default values as does this similar manpage for OpenBSD.
If you compare the two manpages linked in the preceding paragraph you may notice a syntax different between the two. In some distributions of OpenSSH you may be able to use “+” and “-” to add and remove options from the Ciphers and KexAlgorithms configuration options, meaning a pair of lines such as:
KexAlgorithms +diffie-hellman-group-exchange-sha1 Ciphers +aes256-cbc
may be all you need. I have verified this syntax works for Ubuntu 16.04 and it is documented to work with Debian Stretch (supporting the “”+” option only). Debian Jessie however does not support this, so you’ll need to list all algorithms you wish to use, such as:
Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes256-cbc KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
As noted previously, depending on the firmware version involved, you may not need to adjust the Ciphers value.
Once you add these lines to /etc/ssh/sshd_config, you’ll need to restart sshd. You could do this using the command “/etc/init.d/ssh restart” or restarting the system. You’ll probably want to verify you have an additional way to access your system before restarting this, as if you make an error in the configuration file you may not have ssh based access to your system.
After restarting sshd, you should be able to successfully transfer firmware and bootcode files to your switch.
It is probably worth noting that these protocols and algorithms were disabled for a reason, so you probably don’t want to make these changes on systems that are accessible beyond your security/administrative boundary. Also, if you have specified a full list, rather than adding to, you’ll need to keep that list up over time to reflect changes in practice.
