How to disable SSH cipher/ MAC algorithms for Linux and Unix

How to disable SSH cipher/ MAC algorithms for Linux and Unix


Some of the security concerns, you may need to change  SSH’s cipher/MAC and key algorithms. I added basic steps about how to change these configurations for  Unix and Linux.

Check existing configuration

Check allowed ciphers, macs, and key algorithms before disable.

# sshd -T | grep "\(ciphers\|macs\|kexalgorithms\)"
gssapikexalgorithms gss-gex-sha1-,gss-group1-sha1-,gss-group14-sha1-
ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc
macs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
kexalgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Edit SSHD Configuration

You should disable ciphers and macs using the commands below.  Remove macs and ciphers that you don’t want to allow then save the file. If there is no ciphers and macs configuration on the  SSHD config file, add a new line to the end of the file.

#vi  /etc/ssh/sshd_config

ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc

macs hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512
#service sshd restart

Check the new configuration

# sshd -T | grep "\(ciphers\|macs\|kexalgorithms\)"

 

OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default. This page describes what to do when OpenSSH refuses to connect with an implementation that only supports legacy algorithms.

When an 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
  • HostkeyAlgorithms: the public key algorithms accepted for an SSH server to authenticate itself to an SSH client
  • Ciphers: the ciphers to encrypt the connection
  • MACs: the message authentication codes used to detect traffic modification

For a successful connection, there must be at least one mutually-supported choice for each parameter.

If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:

Unable to negotiate with legacyhost: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

In this case, the client and server were unable to agree on the key exchange algorithm. The server offered only a single method diffie-hellman-group1-sha1. OpenSSH supports this method, but does not enable it by default because it is weak and within theoretical range of the so-called Logjam attack.

Several related options come into play later during user authentication.

  • PubkeyAcceptedKeyTypes (ssh/sshd): the public key algorithms that will be attempted by the client, and accepted by the server for public-key authentication (e.g. via .ssh/authorized_keys)
  • HostbasedKeyTypes (ssh) and HostbasedAcceptedKeyTypes (sshd): the key types that will be attempted by the client, and accepted by the server for host-based authentication (.e.g. via .rhosts or .shosts)

A mismatch between the client and server during authentication will cause authentication to fail, despite it appearing to be configured. For example, an ssh-dss user key may be listed in .ssh/authorized_keys but may not pass authentication because, by default, sshd does not accept this key type.

The best resolution for these failures is to upgrade the software at the other end and/or replace the weak key types with safer modern types. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. This might not be immediately possible in some cases, so you may need to temporarily re-enable the weak algorithms to retain access.

For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithms option, either on the command line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@legacyhost

or in the ~/.ssh/config file:

Host somehost.example.org
	KexAlgorithms +diffie-hellman-group1-sha1

The '+' before the list instructs ssh to append the algorithm to the client's default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.

Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:

Unable to negotiate with legacyhost: no matching host key type found. Their offer: ssh-dss

OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostKeyAlgorithms configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost

or in the ~/.ssh/config file:

Host somehost.example.org
	HostKeyAlgorithms +ssh-dss

Depending on the server configuration, it's possible for other connection parameters to fail to negotiate. You might find the Ciphers and/or MACs configuration options useful for enabling these. It's also possible to query which algorithms ssh supports:

ssh -Q cipher       # List supported ciphers
ssh -Q mac          # List supported MACs
ssh -Q key          # List supported public key types
ssh -Q kex          # List supported key exchange algorithms

Finally, it's also possible to query the configuration that ssh is actually using when attempting to connect to a specific host, by using the -G option:

ssh -G user@somehost.example.com

which will list all the configuration options, including the chosen values for the CiphersMACsHostKeyAlgorithms and KexAlgorithms parameters.

 

ssh –vv Servername ciphers listed
ssh –Q kex
ssh -Q cipher
ssh -Q cipher-auth
ssh -Q mac
ssh -Q kex
ssh -Q key
nmap --script ssh2-enum-algos -sV -p <port> <host>
 
 
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256,hmac-sha2-512


https://github.com/jtesta/ssh-audit/

https://nfsec.pl/


 
0 (0)
Article Rating (No Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
RHCS6: Debug and test multicast traffic between two hosts
Viewed 4554 times since Sun, Jun 3, 2018
zabbix linux How to solve apache error No space left on device: Cannot create SSLMutex
Viewed 468 times since Wed, Nov 11, 2020
AIX, Installation, NIM↑ Creating an LPP source and SPOT in NIM
Viewed 11551 times since Fri, Apr 19, 2019
An easier way to manage disk decryption at boot with Red Hat Enterprise Linux 7.5 using NBDE
Viewed 4635 times since Mon, Aug 6, 2018
replacing (hot-swap) failed disk in rootvg
Viewed 7980 times since Thu, Sep 20, 2018
To do a quick check on the number of path present (does not mean all are Enabled] using for loop
Viewed 2229 times since Fri, Jun 8, 2018
RHEL: Reinstalling Boot Loader on the Master Boot Record (MBR)
Viewed 1958 times since Sun, May 27, 2018
Kerberos authentication configuration for AIX servers
Viewed 8294 times since Mon, Jun 25, 2018
RHEL7 slow ssh login
Viewed 2651 times since Tue, Aug 6, 2019
How to manage Linux password expiry with the chage command
Viewed 10059 times since Tue, Sep 11, 2018