Bug 2060232
| Summary: | openssl-3.0.4-14 does not allow ssh-rsa host keys for ssh | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Brian Stinson <bstinson> | ||||||||
| Component: | openssh | Assignee: | Dmitry Belyavskiy <dbelyavs> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Marek Havrila <mhavrila> | ||||||||
| Severity: | medium | Docs Contact: | Jan Fiala <jafiala> | ||||||||
| Priority: | medium | ||||||||||
| Version: | 9.0 | CC: | dbelyavs, fge, griffint, jafiala, jjelen, jwboyer, mhavrila, pizhang, rduda, rpbikker, tscherf | ||||||||
| Target Milestone: | rc | Keywords: | Reopened, Triaged | ||||||||
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Known Issue | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-06-07 09:05:33 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Brian Stinson
2022-03-03 02:40:39 UTC
*** Bug 2060855 has been marked as a duplicate of this bug. *** *** Bug 2063610 has been marked as a duplicate of this bug. *** Workaround: update-crypto-policies --set LEGACY Closing this as the behavior is intentional The behavior is intentional, but the error message should be improved on the openssh side. It should fail with the normal "no common hostkey algorithms" rather than "error in libcrypto". Normally, this would be handled by the crypto policies, which OpenSSH follows, but this does not apply for hostkey algorithms because setting them from c-p makes them ordered, which is not the intention and breaks later ordering based on local keys in known_hosts. I proposed a change for OpenSSH to handle this in https://bugzilla.mindrot.org/show_bug.cgi?id=2924 three years ago. Other option might be using the non-public openssl API to detect the rsa-sha1 support at runtime to fail cleaner. Reopening and moving to OpenSSH as I believe this deserves some more attention. I agree with your evaluation, but reduce the priority. Thanks! (In reply to Jakub Jelen from comment #11) > The behavior is intentional, but the error message should be improved on the > openssh side. It should fail with the normal "no common hostkey algorithms" > rather than "error in libcrypto". As discussed with Simo, I've opened the following BZ for the error message improvements: https://bugzilla.redhat.com/show_bug.cgi?id=2068423 *** Bug 2073009 has been marked as a duplicate of this bug. *** Just FYI, one of the services that suffers from this error is AWS CodeCommit, when trying to clone a git repository using an SSH URL on RHEL 9. I've confirmed that the 'LEGACY' workaround solves the problem. I'm getting this error on a Centos Stream 9 host when connecting to Fedora 35 hosts. They are running the same version of openssh (8.7p1), with exactly the same crypto-policies for opensshserver, openssh and openssl. The ssh_host_rsa_keys on the Fedora hosts were newly generated under the DEFAULT crypto-policies (3072 bits). I don't know of any way to check whether sha1 is used for signing the keys or not. The only obvious difference is that Fedora 35 uses libcrypto from openssl-libs 1.1.1n and CS9 uses openssl-libs 3.0.1. Furthermore, this error isn't purely cosmetic. It seems to stop the UpdateHostKeys process, as in that the ECDSA host keys also presented by the Fedora hosts are never added to the known_hosts file. (In reply to Reinier Bikker from comment #17) > I'm getting this error on a Centos Stream 9 host when connecting to Fedora > 35 hosts. They are running the same version of openssh (8.7p1), with exactly > the same crypto-policies for opensshserver, openssh and openssl. The > ssh_host_rsa_keys on the Fedora hosts were newly generated under the DEFAULT > crypto-policies (3072 bits). I don't know of any way to check whether sha1 > is used for signing the keys or not. The only obvious difference is that > Fedora 35 uses libcrypto from openssl-libs 1.1.1n and CS9 uses openssl-libs > 3.0.1. > > Furthermore, this error isn't purely cosmetic. It seems to stop the > UpdateHostKeys process, as in that the ECDSA host keys also presented by the > Fedora hosts are never added to the known_hosts file. You have probably some configuration that enforces ssh-rsa signature type somewhere. Please, share your complete client and server configuration and debug logs if you want somebody to have a look into your issue more. Fedora 35 supports RSA with SHA2 so there is no reason why it should not work with default/sane configuration. Created attachment 1885062 [details]
sshd -T on the F35 server
Created attachment 1885075 [details]
"ssh -G F35-server" on the CS9 client
Created attachment 1885077 [details]
"ssh -vvv F35server" form CS9 client
Oh, yeah. It was bug in OpenSSH <8.9 servers: https://bugzilla.mindrot.org/show_bug.cgi?id=3375 Would be great if we would have this backported or rebased finally, but please open a separate bug for this as it is not completely related to the original issue. I think this patch (or at least, my original version of this patch) is implemented in our code. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |