Dealing with legacy issues around Red Hat crypto versions? Here's a fix

If you're running a mixture of new and old RHEL versions, you may have problems SSHing from new to old. Luckily, someone has worked out a handy way around it. The issue is relatively simple: the default security settings in RHEL 9 mean that you can't open an SSH connection to a machine running RHEL 6 or older, which use the …

[b0llchit]

Not encryption but hashing

...the pesky old SHA-1 encryption algorithm...

The SHA-1 algorithm has no encryption properties whatsoever. It cannot encrypt or decrypt anything at all.

The SHA-1 algorithm is a hashing algorithm used to identify a message or block of data in a unique way but using only a small string of numbers, or hash value.

However, as noted, the old algorithm cannot uniquely identify messages or data because collisions have been found (same hash value for different input). You can no longer use the hash value for identification/integrity purposes once collisions are known to happen and the algorithm must be retired.

[Anonymous Coward]

Re: Not encryption but hashing

It's still a cryptographic hash. You may use hash functions that does not fulfill the proprieties of a cryptographic hash. For example in using an hash table you're going to use a hash algorithm but probably not a cryptographic one - which might require more CPU cycles than needed.

[b0llchit]

Re: Not encryption but hashing

...cryptographic hash...

Yes, but that says something about the quality of the hash algorithm used. To qualify it must adhere to cryptographic principles. Actually, being a bit pedantic, SHA-1 lost the "cryptographic" qualification once collisions were detected and exploited.

It still has nothing to do with encryption or decryption because a hash is strictly one-way and encryption can be undone with decryption. You can never ever reverse a hash; the data is lost in the process of hashing and reduced to a hash value.

[chasil]

hmac

The use of hmac-sha1 remains secure, as hmac tolerates a weak hashing algorithm that is prone to collisions (which means that hmac-md5 is also still secure). However, sha-1 is also used within the original RSA key specification, which also cannot be used with modern SSH.

One easy solution is to install tinysshd on the RHEL6 release, which supports the latest (DJB) ciphers. It can be somewhat more difficult to use, as only ed25519 keys are allowed for logins (it does not allow a login with a password).

EPEL for RHEL9 does not yet have PuTTY packages. When they arrive, they will support the older ciphers. They can also be built from source.

[OhForF']

Not existence but feasible to find collisions

>You can no longer use the hash value for identification/integrity purposes once collisions are known to happen<

The algorithm is considered broken if it becomes feasible to find those collisions - not when collisions are known to happen

For SHA-1 there are known attacks that take less effort than brute forcing it thus it is considered broken.

If the number of possible different inputs to an hash algorithm is bigger than the number of different hash values collisions are known (even guaranteed) to exist.

As long as it is difficult to find any collisions the hash algorithm is still fine.

[b0llchit]

Re: Not existence but feasible to find collisions

Indeed, find or knowingly provoke collisions.

[DS999]

I created an alias a few years ago

alias oldssh='ssh -oKexAlgorithms=+diffie-hellman-group1-sha1'

That way I only sacrifice security on connections I decide, rather than making it a global fallback.

[Anonymous Coward]

How many angels can stand on the point of a pin?

SolarWinds.

Gigabytes stolen in an Equifax hack.

Peter Thiel owns all the data describing 60 million NHS patient records.

Fujitsu puts hundreds of innocent people in jail.

.....and so on.......

....and all we get here is some arcane argument about SHA-1.

Maybe someone needs to get a grip!

Just saying!

[Anonymous Coward]

Re: How many angels can stand on the point of a pin?

That response is akin to "People are being murdered every day, and all you can do is talk about computer stuff"

[david 12]

Why is it difficult to add new encryption/hash methods to old OS?

Just curious. What is the difficulty around retrofitting old RH versions with new crypt/hash methods?

[stiine]

Re: Why is it difficult to add new encryption/hash methods to old OS?

My guess is that the sucure versions (SHA256, etc) applications (ssh/sshd/sftp/mod_security) are all dependent on gcc versions that aren't available on RHEL 6, and if you're going to port a recent version of gcc to RHEL 6, you might as well port your applications to RHEL 9.

[chasil]

Re: Why is it difficult to add new encryption/hash methods to old OS?

I have successfully compiled both tinysshd and dropbear on an RHEL5 clone.

They both can solve the RHEL9 connectivity problem. The tinyssh server is more restrictive, but has a better security record than dropbear.

[Henry Wertz 1]

Same with Ubuntu but different solution

I had the same problem trying to connect to voltron, my one system running Ubuntu 11.04 (but a much newer kernel, 5.4.0-109-generic currently) had this issue. They do not supply a update-crypto-polcies command, so I had to put the following into /etc/ssh/ssh_config (and sshd_config so if you want it to be able to connect to a Ubuntu 22.04-running system.)

HostKeyAlgorithms +ssh-rsa

PubkeyAcceptedKeyTypes +ssh-rsa

First line to connect at all, and without the second line I had to supply the password every time, even though my keys were copied over already (ssh-copy-id).