Bug 1666802

Summary:	logging in with rsa cert doesn't appear to work
Product:	Red Hat Enterprise Linux 8	Reporter:	Jakub Jelen <jjelen>
Component:	crypto-policies	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:	Simo Sorce <ssorce>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.1	CC:	nmavrogi, omoris, rik.theys, ssorce, szidek
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.1
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	crypto-policies-20190613-1.git21ffdc8.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1665611	Environment:
Last Closed:	2019-11-05 22:33:24 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:
Bug Depends On:	1665611, 1682515
Bug Blocks:

Description Jakub Jelen 2019-01-16 15:19:32 UTC

+++ This bug was initially created as a clone of Bug #1665611 +++

[...]

--- Additional comment from Jakub Jelen on 2019-01-16 16:06:05 CET ---

I can reproduce the same problem. It really looks like a bug in crypto policy. I probably initially forgot to include the sha2 variants (they are not listed in `ssh -Q key`). Even though the log says it is plain rsa certificate, when I dumped what is actually being compared to what, I figured out it is really the SHA2 signature already, which was missing in the list from the crypto policy.

userauth_pubkey: pkalg=<rsa-sha2-512-cert-v01> PubkeyAcceptedKeyTypes=<rsa-sha2-256,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01,rsa-sha2-512,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01,ssh-ed25519,ssh-ed25519-cert-v01,ssh-rsa,ssh-rsa-cert-v01> [preauth]

I filled the following pull request resolving this upstream:

https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/35

And I reassign the bug to crypto policies.

Comment 2 Tomas Mraz 2019-01-17 09:48:33 UTC

I do not think this is that common. Also I do not see it would "lock out" someone unexpectedly. It would not work from start. For that reason I think this can be safely postponed to 8.1.

Comment 13 Simo Sorce 2019-07-08 16:18:16 UTC

Verified via CI: https://baseos-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/ci-openstack/29584//console

[10.0.132.116        ] T:       4 [OS/openssh/Sanity/public-key-authentication] Running
[10.0.132.116        ] 1562575718 [Setup                                      ] PASS Score: 0
[10.0.132.116        ] 1562575719 [ng-user-certificates-with-SHA-256-signature] PASS Score: 0
[10.0.132.116        ] 1562575720 [ng-user-certificates-with-SHA-512-signature] PASS Score: 0
[10.0.132.116        ] 1562575721 [o-for-user-certificate-with-SHA-2-signature] PASS Score: 0
[10.0.132.116        ] 1562575722 [ng-host-certificates-with-SHA-256-signature] PASS Score: 0
[10.0.132.116        ] 1562575723 [Cleanup                                    ] PASS Score: 0

Comment 17 errata-xmlrpc 2019-11-05 22:33:24 UTC

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, 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-2019:3644