Difference between revisions of "Enable Legacy Cipher in Linux for SecureCRT"

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search
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 12: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.

references