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.
Bug 2106556 - sudo failed publickey authentication with pam_ssh_agent_auth
Summary: sudo failed publickey authentication with pam_ssh_agent_auth
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: openssh
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Dmitry Belyavskiy
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-13 01:47 UTC by quanm_qiu
Modified: 2022-11-14 09:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-14 08:21:19 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github jbeverly pam_ssh_agent_auth issues 39 0 None open Auth failure on Centos9 Stream 2022-07-19 13:54:59 UTC
Red Hat Issue Tracker CRYPTO-7929 0 None None None 2022-07-19 13:59:41 UTC
Red Hat Issue Tracker RHELPLAN-127538 0 None None None 2022-07-13 01:50:00 UTC

Description quanm_qiu 2022-07-13 01:47:44 UTC 
Description of problem:
SSH login with yubikey successed. pam_ssh_agent_auth was installed. While run command "sudo su -", it still ask me to enter password after yubikey being touched.

Version-Release number of selected component (if applicable):
pam_ssh_agent_auth-0.10.4-4.8.el9

How reproducible:
RHEL9 minimal install. SElinux disabled.

Steps to Reproduce:
1. dnf install pam_ssh_agent_auth -y
2. add a line on top of /etc/pam.d/sudo "auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys"
3. add a line to /etc/sudoers "Defaults    env_keep += "SSH_AUTH_SOCK""
4. add publickey to ~/.ssh/authorized_keys. directory mod 0700, file mod 0600
5. login user with yubikey
6. run "sudo su -" after login

Actual results:
it still ask me to enter password after yubikey being touched.

Expected results:
just yubikey to be touched, no password prompt

Additional info:

log:

Jul 13 01:32:27 host sshd[4833]: Accepted publickey for testuser from xxx.xxx.xxx.xxx port 56453 ssh2: RSA SHA256:key
Jul 13 01:32:27 host systemd-logind[756]: New session 43 of user testuser.
Jul 13 01:33:15 host sudo[4818]: Beginning pam_ssh_agent_auth for user testuser 
Jul 13 01:33:15 host sudo[4818]: Attempting authentication: `testuser' as `testuser' using /home/testuser/.ssh/authorized_keys
Jul 13 01:33:15 host sudo[4818]: Contacted ssh-agent of user testuser (1000)
Jul 13 01:33:15 host sudo[4818]: trying public key file /home/testuser/.ssh/authorized_keys
Jul 13 01:33:15 host sudo[4818]: auth_secure_filename: checking for uid: 1000
Jul 13 01:33:15 host sudo[4818]: secure_filename: checking '/home/testuser/.ssh'
Jul 13 01:33:15 host sudo[4818]: secure_filename: checking '/home/testuser'
Jul 13 01:33:15 host sudo[4818]: secure_filename: terminating check at '/home/testuser'
Jul 13 01:33:15 host sudo[4818]: matching key found: file/command /home/testuser/.ssh/authorized_keys, line 1
Jul 13 01:33:15 host sudo[4818]: Found matching RSA key: SHA256:key
Jul 13 01:33:18 host sudo[4818]: Failed Authentication: `testuser' as `testuser' using /home/testuser/.ssh/authorized_keys
Jul 13 01:33:28 host sudo[4818]: pam_unix(sudo:auth): conversation failed


SSH publickey login successed with agent forwarding and yubikey. 

ssh-agent -s:
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXcOBDhL/agent.5565; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5566; export SSH_AGENT_PID;
echo Agent pid 5566;

ssh-add -L:
ssh-rsa key cardno:xxxxxx

All running normally. I can't find the reason why sudo failed publickey authentication.
Comment 1 Iker Pedrosa 2022-07-13 07:18:10 UTC 
This PAM module is provided by openssh so I'm changing the ownership.
Comment 2 Ralf Ertzinger 2022-07-17 17:25:58 UTC 
I'm running the same pam/sudo/authorizied_keys configuration (through ansible) on C7, C8S, C9S and Fedora. It works on all of them, except on C9S.

I've raised an issue upstream as well (https://github.com/jbeverly/pam_ssh_agent_auth/issues/39) but given that this part of the code is being patched it might be a RHEL specific issue.
Comment 3 Dmitry Belyavskiy 2022-07-17 17:51:34 UTC 
It may be a duplicate of rhbz#2070113

If so, it's fixed recently
Comment 4 Ralf Ertzinger 2022-07-17 19:55:56 UTC 
That looks like it could be related, although I'm not getting any errors on the ssh-agent side (a F35 system) that I can see.
Comment 5 Dmitry Belyavskiy 2022-07-19 13:54:59 UTC 
Could you please confirm that the LEGACY or DEFAULT:SHA1 crypto policy resolves the problem? If so, it is a duplicate of rhbz#2070113 with high probability and will be fixed in 9.1
Comment 6 quanm_qiu 2022-07-21 02:10:24 UTC 
Reboot after run command update-crypto-policies --set DEFAULT:SHA1, the problem disappeared.

But my pubkey format is SHA256:xxx. It has nothing to do with SHA1.

(In reply to Dmitry Belyavskiy from comment #5)
> Could you please confirm that the LEGACY or DEFAULT:SHA1 crypto policy
> resolves the problem? If so, it is a duplicate of rhbz#2070113 with high
> probability and will be fixed in 9.1
Comment 7 Dmitry Belyavskiy 2022-07-21 07:19:31 UTC 
The problem is that SHA1 has is signed to prove the ownership of RSA key. Patch introduced to fix rhbz#2070113 explicitly tries sha256 for RSA keys.
Comment 8 quanm_qiu 2022-07-21 07:38:55 UTC 
Another problem also disappeared after running update-crypto-policies --set DEFAULT:SHA1 in RHEL 9.0.

I'm trying to setup a SSH hostbased authentication cluster with RHEL 9.0. Passwordless login between nodes always failed:

```
debug3: authmethod_lookup hostbased
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled hostbased
debug1: Next authentication method: hostbased
debug3: userauth_hostbased: trying key type ssh-ed25519
debug1: userauth_hostbased: trying hostkey ssh-ed25519 SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=3040, exec /usr/libexec/openssh/ssh-keysign
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,hostbased
debug3: userauth_hostbased: trying key type ssh-ed25519
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp256
debug1: userauth_hostbased: trying hostkey ecdsa-sha2-nistp256 SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=3041, exec /usr/libexec/openssh/ssh-keysign
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,hostbased
debug3: userauth_hostbased: trying key type ssh-rsa
debug1: userauth_hostbased: trying hostkey ssh-rsa SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=3042, exec /usr/libexec/openssh/ssh-keysign
ssh-keysign: sshkey_sign failed: error in libcrypto
ssh_keysign: no reply
sign using hostkey ssh-rsa SHA256:xxxxxxx failed
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
```

After running update-crypto-policies --set DEFAULT:SHA1, Passwordless login between nodes working too:
```
debug3: authmethod_lookup hostbased
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled hostbased
debug1: Next authentication method: hostbased
debug3: userauth_hostbased: trying key type ssh-ed25519
debug1: userauth_hostbased: trying hostkey ssh-ed25519 SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=1628, exec /usr/libexec/openssh/ssh-keysign
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,hostbased
debug3: userauth_hostbased: trying key type ssh-ed25519
debug3: userauth_hostbased: trying key type ecdsa-sha2-nistp256
debug1: userauth_hostbased: trying hostkey ecdsa-sha2-nistp256 SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=1629, exec /usr/libexec/openssh/ssh-keysign
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,hostbased
debug3: userauth_hostbased: trying key type ssh-rsa
debug1: userauth_hostbased: trying hostkey ssh-rsa SHA256:xxxxxxx
debug2: userauth_hostbased: chost node01.
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug3: ssh_keysign: [child] pid=1630, exec /usr/libexec/openssh/ssh-keysign
debug3: send packet: type 50
debug2: we sent a hostbased packet, wait for reply
debug3: receive packet: type 52
Authenticated to node02 ([192.168.1.2]:22) using "hostbased".
debug1: pkcs11_del_provider: called, provider_id = (null)
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00 want_reply 0
debug3: receive packet: type 4
debug1: Remote: Accepted for node01 [192.168.1.1] by /etc/ssh/shosts.equiv.
debug3: receive packet: type 4
debug1: Remote: Accepted for node01 [192.168.1.1] by /etc/ssh/shosts.equiv.
debug3: receive packet: type 4
debug1: Remote: Accepted for node01 [192.168.1.1] by /etc/ssh/shosts.equiv.
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
```
Comment 9 Jakub Jelen 2022-08-01 10:27:24 UTC 
(In reply to quanm_qiu from comment #6)
> Reboot after run command update-crypto-policies --set DEFAULT:SHA1, the
> problem disappeared.
> 
> But my pubkey format is SHA256:xxx. It has nothing to do with SHA1.

This is just fingerprint format. It does not say anything about signature digest. It is visible only in the debug logs.

> I'm trying to setup a SSH hostbased authentication cluster with RHEL 9.0. Passwordless login between nodes always failed:

I think this is a bug #2088916 which should be fixed also with the recent build in centos9stream (-12.el9). Can you check?
Comment 10 Marek Havrila 2022-11-09 13:29:36 UTC 
I believe both of described issues are fixed in RHEL-9.1. Could you please confirm it so we can close this bug?

Regards,
Marek
Comment 11 quanm_qiu 2022-11-14 03:14:47 UTC 
Thanks. The problems disappeared in 9.1

(In reply to Marek Havrila from comment #10)
> I believe both of described issues are fixed in RHEL-9.1. Could you please
> confirm it so we can close this bug?
> 
> Regards,
> Marek
Comment 12 Dmitry Belyavskiy 2022-11-14 08:21:19 UTC 
Thank you for confirmation!
Comment 13 Ralf Ertzinger 2022-11-14 09:20:03 UTC 
Can confirm that pam_ssh_agent_auth-0.10.4-5.24.el9.x86_64 on c9s no longer requires enabling SHA1
Note You need to log in before you can comment on or make changes to this bug.