in /etc/ssh/sshd_config, PAM is enabled by default on Debian 10:
UsePAM yes In a situation when I don't want to allow login with password or kerberos, and only want to allow SSH key authentication, does it still have any advantage to enable PAM in sshd? Or, would it simplify the process and perhaps make it more secure, if UsePAM is set to no?
What would be the practical effects of disabling PAM in sshd? Would I notice any difference?
Contrary to what the manpage (and another answer) claims, UsePAM yes not only allows you to run sshd as a non-root user, but also allows a sshd running as non-root user to perform password authentication (for the same user it's running as) via the setuid /sbin/unix_chkpwd program.
The latter of which is quite unexpected.
user$ /usr/sbin/sshd -f /dev/null -p 9009 -h ~/.ssh/id_rsa user$ /usr/sbin/sshd -f /dev/null -o UsePAM=yes -p 7007 -h ~/.ssh/id_rsa user$ ssh -p 7007 localhost The authenticity of host '[localhost]:7007 ([::1]:7007)' can't be established. ... Password: <correct password> Linux deb11 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 ... user$ <I'm logged in!> user$ ^D Connection to localhost closed. user$ ssh -p 9009 localhost The authenticity of host '[localhost]:9009 ([::1]:9009)' can't be established. ... user@localhost's password: Permission denied, please try again. user@localhost's password: Permission denied, please try again. user@localhost's password: user@localhost: Permission denied (publickey,password,keyboard-interactive). user$ UsePrivilegeSeparation, which is now deprecated: serverfault.com/a/861842 The manpage explains UsePAM does not only offer authentication, but also session processing. There are a lot of PAM modules which offer a wide range of functionality, including automatic keyring unlocking, mounting file-systems, decrypting private data, selectively permitting logon,…
In ancient times, when UsePAM was set to "yes", sshd required root priviledges. Depending on the use-case, running as a non-root user may help with security or configuration.
I can imagine there are situations when this can come in handy. For example, git uses ssh as a transport protocol. I may want to setup a git server, but I do not want to manage the git users via PAM at all.
I looked into the source of OpenSSH for this.
It seems that having UsePAM might indirectly or directly leak your env according to the auth-pam.c comment I found here in lines 378-382 (link here):
/* * XXX this possibly leaks env because it is not documented * what pam_putenv() does with it. Does it copy it? Does it * take ownweship? We don't know, so it's safest just to leak. */ Also in the same source code I found this interesting content:
/* * Some silly PAM modules (e.g. pam_time) require a TTY to operate. * sshd doesn't set the tty until too late in the auth process and * may not even set one (for tty-less connections) */ It also seems that password authentication is attempted via PAM on line 1351 and a anti-timing attacks mitigation is used in this code.
Since it's defined in a if clause all this auth-pam.c code does not get executed so I would set to no if your security settings allow you to.
So in my opinion I would rather set it to no and don't lose sleep over it anymore.
There's also this opinion: https://askubuntu.com/questions/1259848/
It seems that SSH public key auth might fail if you setup your settings badly: https://serverfault.com/questions/475880
I would also recommend reading this conclusion at the end of the Configuring accounts section:
