RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
It turns out that LEGACY crypto policy prefers weaker algorithms (ssh-rsa) to SHA2 based (rsa-sha2-256) in public keys algorithms for SSH, which causes it failing to authenticate to FIPS servers, which do not allow these weaker algorithms.

OpenSSH is trying the first supported algorithm (from the RSA variants) that is in the list and as there is no way to negotiate what the server supports, it fails after one attempt.

This problem does not happen in DEFAULT policy, as it already has the SHA2 variants in front of the SHA1.

Version-Release number of selected component (if applicable):
all RHEL8 versions

How reproducible:
deterministic

Steps to Reproduce:
1. Configure FIPS system as a SSH server
2. Configure client with LEGACY crypto policy 
3. Generate rsa key on client, copy the public key to the server
4. Try to connect using publickey authentication

Actual results:
the server rejects our key:
sshd[19281]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]

Expected results:
The key is sent with rsa-sha2-256/512 sig type and is accepted by server.

Will changing the order for LEGACY policy cause any issues trying to connect to older servers that support only sha-rsa and no the (now preferred) rsa-sha2-256/512 algorithms ?

(In reply to Simo Sorce from comment #1)
> Will changing the order for LEGACY policy cause any issues trying to connect
> to older servers that support only sha-rsa and no the (now preferred)
> rsa-sha2-256/512 algorithms ?

As far as I know, it should not, at least for OpenSSH.

The servers supporting rsa-sha2 need to advertise these algorithms in the server-sig-alg extension [1] and the client should send the SHA2 signatures only to the servers that support it and fall back to legacy ssh-rsa algorithm otherwise.

[1] https://tools.ietf.org/html/rfc8308#section-3.1

We definitely want this.

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 (crypto-policies bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4536