Bug 2084528

Summary: pam_ssh_agent_auth is working with sudoedit but not with sudo
Product: [Fedora] Fedora Reporter: percy
Component: opensshAssignee: Dmitry Belyavskiy <dbelyavs>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: 36CC: crypto-team, dbelyavs, dwalsh, jjelen, lkundrak, mattias.ellert, tm
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-25 15:51:35 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 percy 2022-05-12 11:21:00 UTC
Description of problem:
after installing pam_ssh_agent_auth and adding
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
line either to /etc/pam.d/sudo or via authselect system is authorizing properly in case sudoedit is invoked but there is no ssh-agent authentication in case of running sudo.


Version-Release number of selected component (if applicable):
0.10.4-5.1.fc36.1

How reproducible:
Every time. Tested with Fedora 36 only.

Steps to Reproduce:
1. sudo dnf -y install pam_ssh_agent_auth
2. add following line to /etc/pam.d/sudo or to /etc/authselect/system-auth: auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
3. run sudo echo test and sudoedit test.file (regardless locally or from remote)

Actual results:
with sudo I am getting password prompt, with sudoedit only have to touch yubikey

Expected results:
consistent behaviour: system to wait for yubikey to be touched

Additional info:
sudo log (not working)

maj 12 13:15:36 host sudo[37577]: Beginning pam_ssh_agent_auth for user user
maj 12 13:15:36 host sudo[37577]: Attempting authentication: `user' as `user' using /home/user/.ssh/authorized_keys
maj 12 13:15:36 host sudo[37577]: No ssh-agent could be contacted
maj 12 13:15:36 host sudo[37577]: Failed Authentication: `user' as `user' using /home/user/.ssh/authorized_keys
maj 12 13:15:44 host sudo[37577]: pam_unix(sudo:auth): conversation failed
maj 12 13:15:44 host sudo[37577]: pam_unix(sudo:auth): auth could not identify password for [user]

sudoedit log (working)

maj 12 13:16:01 host sudoedit[37690]: Beginning pam_ssh_agent_auth for user user
maj 12 13:16:01 host sudoedit[37690]: Attempting authentication: `user' as `user' using /home/user/.ssh/authorized_keys
maj 12 13:16:01 host sudoedit[37690]: Contacted ssh-agent of user user (1001)
maj 12 13:16:01 host sudoedit[37690]: trying public key file /home/user/.ssh/authorized_keys
maj 12 13:16:01 host sudoedit[37690]: auth_secure_filename: checking for uid: 1001
maj 12 13:16:01 host sudoedit[37690]: secure_filename: checking '/home/user/.ssh'
maj 12 13:16:01 host sudoedit[37690]: secure_filename: checking '/home/user'
maj 12 13:16:01 host sudoedit[37690]: secure_filename: terminating check at '/home/user'
maj 12 13:16:01 host sudoedit[37690]: matching key found: file/command /home/user/.ssh/authorized_keys, line 1
maj 12 13:16:01 host sudoedit[37690]: Found matching ECDSA-SK key: /key/

Comment 1 Jakub Jelen 2022-05-12 15:38:54 UTC
Does using the following work?

  sudo -E echo test

Do you have the following line in your /etc/sudoers ?

  Defaults    env_keep += "SSH_AUTH_SOCK"

Comment 2 Jakub Jelen 2022-05-12 15:39:21 UTC
*** Bug 2084527 has been marked as a duplicate of this bug. ***

Comment 3 percy 2022-05-12 21:18:55 UTC
Behavior of sudo with -E switch seems to be no different.
Currently I do not have such a line in /etc/sudoers since man for pam_ssh_agent_auth advises it is required only for older OSes however I've started my tests with that line configured.

Comment 4 percy 2022-05-13 04:10:34 UTC
correction:
with sudo -E it seams to work both with local system and over ssh:

maj 13 06:01:48 host sudo[34513]: Beginning pam_ssh_agent_auth for user user
maj 13 06:01:48 host sudo[34513]: Attempting authentication: `user' as `user' using /home/user/.ssh/authorized_keys
maj 13 06:01:48 host sudo[34513]: Contacted ssh-agent of user user (1000)
maj 13 06:01:48 host sudo[34513]: trying public key file /home/user/.ssh/authorized_keys
maj 13 06:01:48 host sudo[34513]: auth_secure_filename: checking for uid: 1000
maj 13 06:01:48 host sudo[34513]: secure_filename: checking '/home/user/.ssh'
maj 13 06:01:48 host sudo[34513]: secure_filename: checking '/home/user'
maj 13 06:01:48 host sudo[34513]: secure_filename: terminating check at '/home/user'
maj 13 06:01:48 host sudo[34513]: matching key found: file/command /home/user/.ssh/authorized_keys, line 1
maj 13 06:01:48 host sudo[34513]: Found matching ECDSA-SK key: SHA256:/key/
maj 13 06:01:51 host sudo[34513]: Authenticated (agent): `user' as `user' using /home/user/.ssh/authorized_keys

Comment 5 Jakub Jelen 2022-05-13 08:55:01 UTC
Because the documentation is wrong. It is already updated in upstream, but not yet in Fedora:

https://github.com/jbeverly/pam_ssh_agent_auth/pull/29/files

I am not sure when we will have a new upstream release, but this can be fixed as a backport of documentation to prevent confusing users.

Even better solution would be if the pam_ssh_agent_auth dropped this snippet into the /etc/sudoers.d/ directory so the users would not have to bother with this. The file is in the repository, with the template, but it is not installed:

https://github.com/jbeverly/pam_ssh_agent_auth/blob/master/pam_ssh_agent_auth.sudoers.conf

Comment 6 Ben Cotton 2023-04-25 17:08:50 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 7 Ludek Smid 2023-05-25 15:51:35 UTC
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.