Unable to remove cipher suites from ssh

Hello,

This is not Rocky8 related but I hope someone here can land a helping hand as I am at a loss. I asked google and searched openssh forum (inactive since 2013) and did find anything useful.

The ssh from OpenSSH on Rocky 8 supports less secure ciphers such as aes128-cbc. Output of ‘ssh -Q cipher’: 3des-cbc aes128-cbc …

I want to remove all the cbc weak ciphers . However, I cannot seem to do it. I put cipher line in ssh_config and backend config files.

But ‘ssh -Q cipher’ still shows all the -cbc ciphers.

ssh seems to have these ciphers compiled in: strings ssh | grep ‘-cbc’
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Our university security scan shows the server ssh supports weak ciphers and I was asked to remove the weak ciphers.

Does anyone know a way to remove weak ciphers from ssh or tell ssh to not support them?

Thank you.

James Wang

The ssh is a client. Surely it shows what it does support, not what some sshd in some server supports?

The security scan must negotiate with the sshd in your machine. What if you try to connect to your machine, but force your client to use a cbc cipher? Connection should fail if you have successfully removed support.

Hi Jlehtone,

Thanks for your reply.

Our security team required us to have an account on our servers they use to do ‘credential scans’. The scanner reports back saying ssh allows weak ciphers, hex, and macs. The sshd on the servers is fine after I removed weak ciphers,hex,macs in sshd_config. But putting same lines in ssh_config or .ssh/config makes no difference on ssh client. Very weird.

Best,

James

ssh -Q cipher reports on the list of available ciphers, not the ones that have been configured for use.

I don’t think the ssh command even parses the ssh_config or ~/.ssh/config files with the -Q option.

You can demonstrate that by adding a line badline to this file and seeing that ssh localhost errors out but ssh -Q cipher does not.

RHEL8 (Rocky 8.5) now has the concept of “system wide crypto policies”.
man crypto-policies
The idea is to have system wide defaults, as opposed to per application variance.

Thank you sweh! That is it. Followed your suggestion, I can see the ‘ssh -Q cipher’ doesn’t read the ssh_config.

On our server when I did ‘ssh -vv localhost’, I saw (ctos and stoc):

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

That’s what I wanted and I now know what to tell to our security team.

Thanks,

James

Thank you Gerry for the information.

RHEL doc about them has a section about openssh: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#examples-of-opting-out-of-system-wide-crypto-policies_using-the-system-wide-cryptographic-policies

And here is a article about changing a crypto policy

Hi anemarkus

Thanks for the article! It is a great read. I am so glad that I asked here. I am going to modify our Rocky8 servers based on our university policies.

James

@jamesw , consider the fact the host providing the SSH service requires changes to the KEX, MACs, and Ciphers found in the /etc/ssh/sshd_config file.

Also, if you are reviewing Tenable scans that are providing you feedback about your Compliance results; consider the fact many things the scanner is looking for is expected to literally be in the same order. I use the word literally accurately in this case, because where many people use the word literally too liberally, and they actually mean metaphorically.

Be aware, that if you have RHEL 6 variants that need access to this server, you need to ensure you have hmac-sha1 listed in association with your MACs setting.

Thank you Warron. I will keep it in mind. We do have a few CentOS 6 or older servers and I am in process of upgrading them to Rocky8.

The systemd unit-file for sshd.service contains:

EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY

The man sshd writes: “command-line options override values specified in the configuration file.”
The /etc/crypto-policies/back-ends/opensshserver.config is provided by package crypto-policies and defines CRYPTO_POLICY.

Therefore, your current crypto policy overrides all Ciphers that you set in /etc/ssh/sshd_config.

1 Like

This is also true @jlehtone , but most people know about the configurations listed directly and explicitly in the /etc/ssh/sshd_config file and when the ssh packages are updated it doesn’t matter which file has your updates there will be an rpmsave file created. As such, you will realize the package was updated and you may need to copy back your configurations (most of the time not); so leaving your custom changes in a file that is regularly checked makes it easier for troubleshooting than putting the custom changes into a file that is rarely reviewed if at all.

Yes, but the point was – if we are talking about the ‘Ciphers’ option – that the Ciphers you set in /etc/ssh/sshd_config are completely ignored.

Yes, you might get rpmnew/rpmsave when ‘openssh-server’ is updated, but the actual changes to Ciphers are in different package, file, and directory.

Furthermore, for ciphers in ssh client, the /etc/ssh/ssh_config ends with:

# This system is following system-wide crypto policy.
# To modify the system-wide ssh configuration, create a  *.conf  file under
#  /etc/ssh/ssh_config.d/  which will be automatically included below
Include /etc/ssh/ssh_config.d/*.conf

The idea is that customizations are added as separate files, so there will be less/no rpmnew/rpmsave. On one hand customizations remain clearly separate from defaults. On the other hand it is less obvious when customizations have to be adapted.

EL8 has /etc/ssh/ssh_config.d/. EL9 will have /etc/ssh/sshd_config.d/ too.

2 Likes