Difference between revisions of "Enable Legacy Cipher in Linux for SecureCRT"
m (→references) |
(→log analysis) |
||
(4 intermediate revisions by one user not shown) | |||
Line 12: | Line 12: | ||
Even though 3des-cbc is enabled in the configuration, the client using 3des-cbc is rejected, as evidence in the log | Even though 3des-cbc is enabled in the configuration, the client using 3des-cbc is rejected, as evidence in the log | ||
cat /var/log/auth.log | cat /var/log/auth.log | ||
+ | You you look at the log entry you will find that there are three possible things that can go wrong during the authentication, assuming the user entered the correct username and password, that point to the problem being an incompatible cipher. In the log entry you will see a complaint like (snip) "...sshd[1528]: fatal: no matching mac found: client hmac-md5 server ...". Here the word "mac" is referenced, meaning a correct cipher was found but the mac "hmac-md5" which is displayed as simply "MD5" in CRT is not enabled on the server. The error entry in the log will reference one of three: no matching cipher, no matching mac, or Unable to negotiate a key exchange method. | ||
It turns out that number of version 2 ciphers have been disabled in the 6.7p1-1 release of openssh. Lets see what version of OpenSSH we have. | It turns out that number of version 2 ciphers have been disabled in the 6.7p1-1 release of openssh. Lets see what version of OpenSSH we have. | ||
Line 50: | Line 51: | ||
Monitor the log while attempting to connect with SecureCRT | Monitor the log while attempting to connect with SecureCRT | ||
tail -f /var/log/auth.log | tail -f /var/log/auth.log | ||
+ | |||
+ | === log analysis === | ||
+ | To help you identify whether it is the cipher, mac, or KexAlgorithms which is not being accepted you can utilize the auth.log. Provided below is an example for each type of entry. If your problem is all three, then keep in mind that once the first fails, the other two will not appear in the log. So, if you correct the issue with the cipher, which was displayed in the log, then there still may remain other issues that have yet to appear in the log until you attempt the connection once again. | ||
+ | |||
+ | Jan 01 01:31:24 servername sshd[1528]: fatal: no matching mac found: client hmac-md5 server 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 [preauth] | ||
+ | |||
+ | Indicates that the cipher is not supported. Correct this by enabling the cipher in /etc/ssh/sshd_config | ||
+ | |||
+ | Jan 01 01:37:05 servername sshd[1538]: fatal: no matching mac found: client hmac-md5 server 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 [preauth] | ||
+ | |||
+ | Indicates that the mac is not supported. Correct this by enabling the mac in /etc/ssh/sshd_config | ||
+ | |||
+ | Jan 01 01:39:26 servername sshd[1606]: fatal: Unable to negotiate a key exchange method [preauth] | ||
+ | |||
+ | Indicates that the KexAlgorithm is not supported. Correct this by enabling the KexAlgorithm in /etc/ssh/sshd_config | ||
+ | |||
+ | Once all the legacy ciphers are enabled in /etc/ssh/sshd_config you must restart the sshd service. These legacy ciphers are not secure. Enabling them is only recommended on a server that is not directly connected to the Internet, only accessible from a secure LAN. | ||
=== references === | === references === | ||
Line 58: | Line 80: | ||
*[https://bbs.archlinux.org/viewtopic.php?id=188613 Archlinux Networking, Server, and Protection, Openssh 6.7 disables a number of ciphers] | *[https://bbs.archlinux.org/viewtopic.php?id=188613 Archlinux Networking, Server, and Protection, Openssh 6.7 disables a number of ciphers] | ||
* [https://bbs.archlinux.org/viewtopic.php?id=189535 Archlinux Newbie Corner, Cannot connect to ssh-server anymore!] | * [https://bbs.archlinux.org/viewtopic.php?id=189535 Archlinux Newbie Corner, Cannot connect to ssh-server anymore!] | ||
+ | |||
+ | [[Category:Computer_Technology]] | ||
+ | [[Category:Linux]] |
Latest revision as of 13:36, 27 February 2017
why it broke
SecureCRT version 3.1.2 has a limited selection of available ciphers. It is an old version of the client. In the past when the selections
- Cipher: 3DES
- MAC: MD5
where used, the client connected to the linux system sshd server (OpenSSH). SecureCRT is actually using the cipher "3des-cbc" specifically and "hmac-md5" for the MAC (Message Authentication Codes).
Supporting legacy ciphers for backwards compatibility is necessary to connect "ssh" with SecureCRT. The ssh server "sshd" ciphers can be configured via the file:
vi /etc/ssh/sshd_config
See what ciphers are available on your system:
ssh -Q cipher localhost ssh -Q mac localhost
Even though 3des-cbc is enabled in the configuration, the client using 3des-cbc is rejected, as evidence in the log
cat /var/log/auth.log
You you look at the log entry you will find that there are three possible things that can go wrong during the authentication, assuming the user entered the correct username and password, that point to the problem being an incompatible cipher. In the log entry you will see a complaint like (snip) "...sshd[1528]: fatal: no matching mac found: client hmac-md5 server ...". Here the word "mac" is referenced, meaning a correct cipher was found but the mac "hmac-md5" which is displayed as simply "MD5" in CRT is not enabled on the server. The error entry in the log will reference one of three: no matching cipher, no matching mac, or Unable to negotiate a key exchange method.
It turns out that number of version 2 ciphers have been disabled in the 6.7p1-1 release of openssh. Lets see what version of OpenSSH we have.
dpkg-query -l|grep -i openssh
Debian Linux Jessie reports openssh-server 1:6.7p1-5+deb8u3 which has the following ciphers disabled: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
* sshd(8): The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. The full set of algorithms remains available if configured explicitly via the Ciphers and MACs sshd_config options.
When a SSH client connects to a server, each side offers lists of connection parameters to the other. These are, with the corresponding ssh_config keyword:
- KexAlgorithms: the key exchange methods that are used to generate per-connection keys
- Ciphers: the ciphers to encrypt the connection
- MACs: the message authentication codes used to detect traffic modification
- PubkeyAcceptedKeyTypes: the public key algorithms that the server can use to authenticate itself to
making it work
To get it up and running using weak ciphers as to support an old version of SecureCRT you must edit the sshd_config file. Before you do that, get a list of ciphers and macs that you can copy to later paste into the sshd_config file:
ssh -Q cipher localhost | paste -d , -s ssh -Q mac localhost | paste -d , -s
Copy that output into the sshd_config file along with a third line. Open sshd_config for editing:
vi /etc/ssh/sshd_config
Add the following lines near the top, under where it says "Protocol 2"
Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-md5-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group1-sha1,curve25519-sha256@libssh.org
Remember we obtained the ciphers and macs from the list we generated with the preceding commands. Now we had to add a third line for the KexAlgorithms.
Restart the sshd service
service sshd restart
Monitor the log while attempting to connect with SecureCRT
tail -f /var/log/auth.log
log analysis
To help you identify whether it is the cipher, mac, or KexAlgorithms which is not being accepted you can utilize the auth.log. Provided below is an example for each type of entry. If your problem is all three, then keep in mind that once the first fails, the other two will not appear in the log. So, if you correct the issue with the cipher, which was displayed in the log, then there still may remain other issues that have yet to appear in the log until you attempt the connection once again.
Jan 01 01:31:24 servername sshd[1528]: fatal: no matching mac found: client hmac-md5 server 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 [preauth]
Indicates that the cipher is not supported. Correct this by enabling the cipher in /etc/ssh/sshd_config
Jan 01 01:37:05 servername sshd[1538]: fatal: no matching mac found: client hmac-md5 server 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 [preauth]
Indicates that the mac is not supported. Correct this by enabling the mac in /etc/ssh/sshd_config
Jan 01 01:39:26 servername sshd[1606]: fatal: Unable to negotiate a key exchange method [preauth]
Indicates that the KexAlgorithm is not supported. Correct this by enabling the KexAlgorithm in /etc/ssh/sshd_config
Once all the legacy ciphers are enabled in /etc/ssh/sshd_config you must restart the sshd service. These legacy ciphers are not secure. Enabling them is only recommended on a server that is not directly connected to the Internet, only accessible from a secure LAN.