pam_ssh_agent_auth(8)

💅 pam_ssh_agent_auth(8) — the PAM module that lets your SSH agent say “she’s with me” ✨

okay bestie, welcome to the manual page for pam_ssh_agent_auth(8) 🫶 yes, that’s the manual name, and no, we’re not skipping the technical bits. Let’s get into it.

🌸 NAME 🌸

pam_ssh_agent_auth — a PAM module for granting permissions based on SSH agent requests. It’s giving “the agent already vouched for me, so let me in.” 💅

✨ DESCRIPTION ✨

okay so this module provides authentication via ssh keys. 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. If the public key originally used to authenticate at sshd matches an authorized key, authentication succeeds. Otherwise authentication fails. That’s the whole plot, no cap. 😌

🛠️ CONFIGURATION 🛠️

Two big setups here: sudo and sshd. Both are lowkey iconic.

👑 SUDO 👑

Pop this into /etc/pam.d/sudo:

auth   sufficient      pam_ssh_agent_auth.so file=/etc/security/authorized_keys

Then in /etc/sudoers, you gotta enable sudo to pass the environment variable pointing to the ssh authentication socket:

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. Both are valid, bestie. 🫶

Unlike NOPASSWD, this still requires an authentication, it’s just that the authentication is provided by ssh-agent, and not password entry. So it’s not “no auth,” it’s “auth by agent.” Important distinction, periodt. 💅

🦋 SSHD 🦋

Your /etc/ssh/sshd_config wants:

PubkeyAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam
PasswordAuthentication no
UsePAM yes

and your /etc/pam.d/sshd wants:

auth required    pam_permit.so
auth   sufficient      pam_ssh_agent_auth.so file=/etc/security/super_authorized_keys
auth sufficient  pam_secondary_auth_method.so
...
auth requisite   pam_deny.so

This configuration would permit anyone who originally authenticated to sshd with a public key also found in /etc/security/super_authorized_keys to log in without having to complete other PAM auth methods. Anyone whose ssh key was accepted initially by sshd but whose key is not in the allowlist must complete another secondary PAM module such as OTP or else be denied. So close, but the allowlist is the vibe check. ✨

⚙️ ARGUMENTS ⚙️

These are the flags and knobs, and every single one gets its moment:

• file=<path to authorized_keys> — 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=<path to executable> — 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=<username> — 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. For when you need the receipts. 🧾
• sudo_service_name=<service name you compiled sudo to use> — (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 🧚

These little symbols expand into paths and host info, iykyk:

• ~ — 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 🌈

Examples time, bestie. These all live in /etc/pam.d/sudo.

Example 1 — the default user key:

"auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys"

The default .ssh/authorized_keys file in a user’s home-directory.

Example 2 — same as above:

"auth sufficient pam_ssh_agent_auth.so file=%h/.ssh/authorized_keys"

Same as above.

Example 3 — ~fred energy:

"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’.

Example 4 — %H and %u with the ownership flag:

"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.

Example 5 — %f FQDN:

"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.

Example 6 — control flow with success=3:

"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 📜

okay legal bestie moment — here’s the copyright and license text, kept exactly as it needs to be. Do not @ me, I’m not editing legal text 💀

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, Liz Fong-Jones, 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.

okay that’s literally the whole manual, bestie 🫶 — this page is from pam_ssh_agent_auth v0.10.3, dated 2022-01-11, and that’s the footer energy, slay 💅✨