--- name: "pam_ssh_agent_auth" section: "8" platform: "linux" package: "libpam-ssh-agent-auth" version: "0.10.3-11" release: "Debian 13 (Trixie)" platforms: ["linux"] url: "https://new.carta.tech/pam_ssh_agent_auth" --- # pam\_ssh\_agent\_auth(8) PAM module for granting permissions based on SSH agent requests ## NAME pam\_ssh\_agent\_auth - PAM module for granting permissions based on SSH agent requests ## DESCRIPTION This module provides authentication via ssh-agent. If an ssh-agent listening at SSH\_AUTH\_SOCK can successfully authenticate that it has the secret key for a public key in the specified file, authentication is granted, otherwise authentication fails. ## CONFIGURATION - /etc/pam.d/sudo: auth sufficient pam\_ssh\_agent\_auth.so file=/etc/security/authorized\_keys - /etc/sudoers: In older versions of sudo (\< 1.8.5) it was necessary to set:\ Defaults env\_keep += "SSH\_AUTH\_SOCK" This configuration would permit anyone who has an SSH\_AUTH\_SOCK that manages the private key matching a public key in /etc/security/authorized\_keys to execute sudo without having to enter a password. Note that the ssh-agent listening to SSH\_AUTH\_SOCK can either be local, or forwarded. Unlike NOPASSWD, this still requires an authentication, it's just that the authentication is provided by ssh-agent, and not password entry. ## ARGUMENTS - file=\ Specify the path to the authorized\_keys file(s) you would like to use for authentication. Subject to tilde and % EXPANSIONS (below) - allow\_user\_owned\_authorized\_keys\_file A flag which enables authorized\_keys files to be owned by the invoking user, instead of root. This flag is enabled automatically whenever the expansions `%h` or ~ are used. - authorized\_keys\_command=\ Specify an external command to run, which should take a single argument, the username of the person being authenticated, and emit to its stdout a file in authorized\_keys format. This is ideally suited for use with sssd's sss\_ssh\_authorizedkeys, for authenticating users via authorized\_keys stored in ldap or other sssd supported security service. - authorized\_keys\_command\_user=\ Specify a user to run the authorized\_keys\_command as. If this option is not specified, the authorized\_keys\_command will be run as the user being authenticated. - debug A flag which enables verbose logging - sudo\_service\_name=\ (when compiled with --enable-sudo-hack) Specify the service name to use to identify the service "sudo". When the PAM\_SERVICE identifier matches this string, and if PAM\_RUSER is not set, pam\_ssh\_agent\_auth will attempt to identify the calling user from the environment variable SUDO\_USER. This defaults to "sudo". ## EXPANSIONS - \~ -- same as in shells, a user's Home directory Automatically enables allow\_user\_owned\_authorized\_keys\_file if used in the context of ~/. If used as ~user/, it would expect the file to be owned by 'user', unless you explicitly set allow\_user\_owned\_authorized\_keys\_file - %h -- User's Home directory Automatically enables allow\_user\_owned\_authorized\_keys\_file - %H -- The short-hostname - %u -- Username - %f -- FQDN ## EXAMPLES in /etc/pam.d/sudo - "auth sufficient pam\_ssh\_agent\_auth.so file=~/.ssh/authorized\_keys" The default .ssh/authorized\_keys file in a user's home-directory - "auth sufficient pam\_ssh\_agent\_auth.so file=%h/.ssh/authorized\_keys" Same as above. - "auth sufficient pam\_ssh\_agent\_auth.so file=~fred/.ssh/authorized\_keys" If the home-directory of user 'fred' was /home/fred, this would expand to /home/fred/.ssh/authorized\_keys. In this case, we have not specified allow\_user\_owned\_authorized\_keys\_file, so this file must be owned by 'fred'. - "auth sufficient pam\_ssh\_agent\_auth.so file=/secure/%H/%u/authorized\_keys allow\_user\_owned\_authorized\_keys\_file" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar/fred/authorized\_keys. In this case, we specified allow\_user\_owned\_authorized\_keys\_file, so fred would be able to manage that authorized\_keys file himself. - "auth sufficient pam\_ssh\_agent\_auth.so file=/secure/%f/%u/authorized\_keys" On a host named foobar.baz.com, and a user named fred, would expand to /secure/foobar.baz.com/fred/authorized\_keys. In this case, we have not specified allow\_user\_owned\_authorized\_keys\_file, so this file must be owned by root. - "auth \[success=3 default=ignore\] pam\_ssh\_agent\_auth.so file=~/.ssh/authorized\_keys debug" This pam.d config format allows for more control over how pam handles success and failure. In this example, we use success=3, which specifies that when this module succeeds, pam should jump over the next 3 auth modules and continue from there. This is useful, for instance, if /etc/pam.d/common-auth is included, and contains 3 "auth required" or similar module rules that we wish to skip, but we wish not to skip other auth rules. For more information, please see http://linux.die.net/man/5/pam.d ## COPYRIGHT ``` Copyright (c) 2008-2014, Jamie Beverly. And is based on openssh, and the included works by Markus Friedl, Darren Tucker, Todd C. Miller, Ben Lindstrom, Tim Rice, Damien Miller, and many others. All rights reserved. See sources for complete attributions. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY Jamie Beverly ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Jamie Beverly OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ```