jbeverly / pam_ssh_agent_auth

Moving pam_ssh_agent_auth to github as primary development location
Other
100 stars 29 forks source link

using it without modifying /etc/sudoers #16

Open bricewge opened 5 years ago

bricewge commented 5 years ago

It is hinted at several places in the repository that it's not needed to modify /etc/sudoers to use this module, for example here: https://github.com/jbeverly/pam_ssh_agent_auth/blob/88c79a04a37d465b793fb7c0e320c30c4e1944d4/pam_ssh_agent_auth.sudoers.conf#L31

I am guessing that, to keep the user's environment variable SSH_AUTH_SOCK up to our module pam_ssh_agent_auth, I need to use the pam_env module. So in /etc/pam.d/sudo, before requiring our module, I added auth required pam_env.so conffile=/myconffile user_readenv=1 whith myconffile containing the one line SSH_AUTH_SOCK. Unfortunately our module, in debugging mode, keep complaining that the ssh-agent can't be contacted.

I tried as much as I could to understand and achieve how to do this but at the end I was forced to keep using /etc/sudoers. My setup was sudo 1.8.27 with pam_ssh_agent_auth 0.10.3 on NixOS 19.03.

It would be nice to either removed those reference if we are forced to use /etc/sudoers or adding to the documentation how to use the module in this alternative way.

srd424 commented 5 years ago

I too am finding I still need to modify sudoers to pass through SSH_AUTH_SOCK.

@bricewge, I think pam_env is irrelevant - it's about setting environment variables to static values.

@jbeverly, what was the change in sudo 1.8.5 which (should) have fixed things? I peered into the sudo changelog and my best guess is:

The policy plugin's init_session function is now called by the parent sudo process, not the child process that executes the command. This allows the PAM session to be open and closed in the same process, which some PAM modules require.

?

kgabor545 commented 2 years ago

I just tried the "pam_env method", because I wanted to use the pam_ssh_agent in polkit-1, but no success.

I tried:

auth       required                   pam_env.so user_envfile=/home/user/.pam_environment user_readenv=1
auth sufficient pam_ssh_agent_auth.so file=/etc/security/sudo_authorized_keys

I probably don't understand how pam works, because it seems it doesn't even open the file. (I monitored with inotifywait) I got pam_ssh_agent_auth: No ssh-agent could be contacted in the syslog. (sudo works well with env_keep) Can anyone help with this?

I suspect pam_env only run on login and not on a simple auth. I think If we had an envfile parameter for pam_ssh_agent module, that could solve both our problems :)

UPDATE: I found a pull request which adds ability to pass auth sock path via parameter which allows you to use the module without modifying the sudoers conf. So I make a symlink on user login: ln -sf $SSH_AUTH_SOCK ~/.ssh_auth_sock and use the module in sudo and polkit-1 like this:

auth sufficient pam_ssh_agent_auth.so file=/etc/security/sudo_authorized_keys default_ssh_auth_sock=%h/.ssh_auth_sock

And this made me wonder, we could add this sock path as default.

nogweii commented 1 year ago

Similarly, you'll need to make another change to allow non-interactive use of sudo with this module:

# allows everyone
Defaults noninteractive_auth

# allows only the ansible user
Defaults:ansible noninteractive_auth

This is required to allow remote connections to be able to sudo, e.g. ssh -A ansible@my-box 'sudo rm /root/foo.txt'. I'm using this module to allow ansible to manage boxes without requiring a password prompt from it.