We are using apache-sshd to execute commands on hypervisors from engine using SSH protocol (for example copy SSH public key to hypervisors, getting VDSM ID, restarting/stopping hosts over SSH, ...).
During connection from engine to host we are checking the fingerprint of the host. But from historical reasons all our code around generating fingerprint from SSH key is built on RSA public keys:
That's why currently we allowing only RSA keys:
Of course apache-sshd supports also other public keys:
We have found out that due to above limitations we cannot connect to EL8 hosts with FIPS security hardening enabled.
This problem is solvable, but it requires significant code changes and probably even breaking backward compatibility around host SSH fingerprints:
We would need to perform following:
1. Save all existing SSH public keys of the host into database
2. If one of above keys is RSA, generate fingerprint and save it to database
3. During SSH connection don't validate fingerprints, but compare stored SSH keys
4. Extend our RESTAPI to provide not only RSA public key fingerprint, but all SSH public keys we have fetched from the host
5. If the host won't have RSA public key available, fingerprint will be empty -> this is breaking backward compatibility for existing clients which relies on existence of fingerprint
Just for the record, there is really nothing wrong with RSA keys as long as they can be used with SHA2 digests per RFC 8332 , but it looks like this RFC is not implemented in apache-sshd (from my fast check of few files).
Therefore accepting different key types (generally ecdsa, which is also supported on apache-sshd side) is something we should strive to in short-term. Implementation of the above RFC can be tricky in many ways, but it would ultimate goal to extend compatibility.
(In reply to Jakub Jelen from comment #1)
> Just for the record, there is really nothing wrong with RSA keys as long as
> they can be used with SHA2 digests per RFC 8332 , but it looks like this
> RFC is not implemented in apache-sshd (from my fast check of few files).
Hmm, right now we are using version 2.2.0, but if I take a look at 2.3.0 release notes, I can see also support for RSA-SHA256 and RSA-SHA512:
So maybe it's also worth trying to upgrade first
> Therefore accepting different key types (generally ecdsa, which is also
> supported on apache-sshd side) is something we should strive to in
> short-term. Implementation of the above RFC can be tricky in many ways, but
> it would ultimate goal to extend compatibility.
>  https://tools.ietf.org/html/rfc8332
Thanks for sharing the link. I did not find the changelog myself. The official project page is very brief .
It indeed looks like they implemented this RFC so in that case, updating to current version (and maybe adjusting your code to support also the rsa-sha2 signatures) would be better as a short-term fix for he previously mentioned issue. Adding support for different key types (ecdsa) would be certainly good for a long-term but would not be a must
I've created BZ1838159 to track upgrade to apache-sshd 2.4.0 to support RSA-SHA256 and and RSA-SHA512 public keys, so moving current bug to 4.5
Martin shouldn't this be re-targeted to 4.4 too?
(In reply to Sandro Bonazzola from comment #5)
> Martin shouldn't this be re-targeted to 4.4 too?
If BZ1838159 will fix the issue, then I'd rather leave this for 4.5 or some 4.4.z
Verified on ovirt-engine-188.8.131.52-0.13.el8ev.noarch
*** Bug 1619649 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.