The SSH authentication service module for PAM, pam_ssh provides functionality for two PAM categories:
authentication and session management. In terms of the module-type parameter, they are the “auth” and
“session” features. It also provides null functions for the remaining categories.
SSHAuthenticationModule
The SSH authentication component verifies the identity of a user by prompting the user for a passphrase
and verifying that it can decrypt at least one of the user's SSH login (or authentication) keys using
that passphrase.
The user's SSH login keys must be either located or symbolically linked into the per-user dedicated
folder ~/.ssh/login-keys.d/ in the user's home directory.
The following options may be passed to the authentication module:
debugsyslog(3) debugging information at LOG_DEBUG level.
use_first_pass
If the authentication module is not the first in the stack, and a previous module obtained the
user's password, that password is used to decrypt the user's SSH login keys. If this fails, then
the authentication module returns failure without prompting the user for a passphrase.
try_first_pass
Similar to the use_first_pass option, except that if the previously obtained password fails to
decrypt any of the SSH login keys, then the user is prompted for an SSH passphrase.
nullok Allow SSH keys with no passphrase.
If neither use_first_pass nor try_first_pass is specified, pam_ssh will unconditionally ask for an SSH
passphrase.
The now deprecated name allow_blank_passphrase for nullok is kept for compatibility reasons.
SSHSessionManagementModule
The SSH session management component initiates sessions by launching an SSH agent, passing it any user's
SSH login keys successfully decrypted during the authentication phase and any additional user SSH session
keys successfully decrypted, and sets dedicated environment variables accordingly; the environment
variable TMPDIR, which can be set through the pam_tmpdir module for instance, is also honoured by being
passed to the SSH agent.
The SSH session management component terminates the session by killing the previously launched SSH agent
by sending it a SIGTERM.
The traditional SSH keys ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, and ~/.ssh/id_ed25519 are
considered as the default SSH session keys. Nonetheless, extra user SSH session keys can be either
located or symbolically linked into the per-user dedicated folder ~/.ssh/session-keys.d/ in the user's
home directory.
Provided that they have been successfully decrypted, the SSH session management passes to the launched
SSH agent first the session SSH keys in lexical order, second the login SSH keys in lexical order, and
finally the traditional SSH keys in the reverse order cited above. Since the SSH agent keeps in its
memory for each passed key its first position (but its last comment), each SSH key rank can be easily
overwritten with an appropriate symbolic link placed in ~/.ssh/session-keys.d/ or ~/.ssh/login-keys.d/;
this is especially true for the traditional SSH keys. The involved lexical order is performed against
the SSH key file basenames (according to the C/POSIX locale character collation rules). Because actually
their basenames are passed as comments, their effective order might be easily checked with an appropriate
SSH agent helper as ssh-add(3). As final remark, keep in mind that the SSH agent may place itself SSH
keys with protocol 1 before SSH keys with protocol 2.
The following option may be passed to the session management module:
debugsyslog(3) debugging information at LOG_DEBUG level.
Install Now
PNG Icons
