Tagged: #sudo #forwardauthentication
February 14, 2022 at 20:51 #37520
Using key-based auth with a PKCS11 smart card and Forward Authentication, I am able to SSH from a terminal window within a NoMachine session without being prompted to authenticate. The secure log verifies that authentication forwarding is working. However, I am prompted for a password when using sudo, with an error:
sudo failed authentication as <user> using /etc/security/authorized_keys.
I am able to add my smartcard to ssh-agent and authenticate sudo successfully in an SSH session outside of NoMachine.
I tried updating /etc/pam.d/nx with the advice posted here, but saw no change: https://forums.nomachine.com/topic/problem-with-sudo-prompt
Server: NoMachine Small Business Server 7.7.4 (RHEL 7). The server is managed by IPA (Red Hat IdM).
auth sufficient pam_ssh_agent_auth.so authorized_keys_command=/usr/bin/sss_ssh_authorized_keys
auth sufficient pam_sss.so
I have also tried session include system-auth and session include sudo in /etc/pam.d/nx, but have not seen any change in behavior.
Any advice on how to update the nomachine config to allow authentication forwarding to work with sudo?
Thanks!February 15, 2022 at 15:20 #37539
I enabled debug for /etc/pam.d/sudo:
auth sufficient pam_ssh_agent_auth.so authorized_keys_command=/usr/bin/sss_ssh_authorizedkeys debug
auth sufficient pam_sss.so
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session required pam_tty_audit.so enable=*
Here are the /var/log/secure entries when I attempt sudo from within a NoMachine session:
Feb 15 14:04:43 lx2-tbw4 sudo: Beginning pam_ssh_agent_auth for user <user>
Feb 15 14:04:43 lx2-tbw4 sudo: Using default file=/etc/security/authorized_keys
Feb 15 14:04:43 lx2-tbw4 sudo: Attempting authentication: <user> as <user> using /etc/security/authorized_keys
Feb 15 14:04:43 lx2-tbw4 sudo: No ssh-agent could be contacted
Feb 15 14:04:43 lx2-tbw4 sudo: Failed Authentication: <user> as <user> using /etc/security/authorized_keys
So, even though the pam_ssh_agent_auth entry in /etc/pam.d/sudo specifies an authorized_keys_command, it is still attempting to use the default file /etc/security/authorized_keys, which doesn’t exist. But, this is only occurring within a NoMachine session – it works external to NoMachine.February 18, 2022 at 11:44 #37624kroyContributor
According to http://pamsshagentauth.sourceforge.net/ authorized_keys_command specifies path to command not a file with keys:
auth sufficient pam_ssh_agent_auth.so authorized_keys_command=/path/to/command
Use /path/to/command, which will receive a single argument, the name of the user authenticating, to look up authorized keys. the output of the command is expected to be in authorized_keys2 format. This runs the command as the user authenticating
/usr/bin/sss_ssh_authorizedkeysis path to file with authorized keys tru set in /etc/pam.d/sudo:
auth sufficient pam_ssh_agent_auth.so file=/usr/bin/sss_ssh_authorizedkeys debugFebruary 18, 2022 at 14:41 #37633
Thank you for the reply.
I modified /etc/pam.d/sudo as you suggested:
auth sufficient pam_ssh_agent_auth.so file=/usr/bin/sss_ssh_authorizedkeys debug
That does stop attempt to use /etc/security/authorized_keys, however sudo does still prompt for a password within a NoMachine session.
Also, with that configuration, auth forwarding for sudo outside of a NoMachine session no longer works. So apparently the authorized_keys_command specification does need to be there.February 21, 2022 at 15:31 #37645kroyContributor
You should revert changes – it looks it’s indeed script, not a file with keys. Are you using physical desktop? If yes – agent forwarding won’t work. Agent forwarding option can be used on virtual and custom sessions (even already existed).
This topic was marked as solved, you can't post.