Bug 2106556

Summary:	sudo failed publickey authentication with pam_ssh_agent_auth
Product:	Red Hat Enterprise Linux 9	Reporter:	quanm_qiu
Component:	openssh	Assignee:	Dmitry Belyavskiy <dbelyavs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9.0	CC:	jjelen, mhavrila, pbrezina, redhat-bugzilla
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-14 08:21:19 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:

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