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).
  • my ssh daemon runs as root (default setting on Debian 10). How can I change to run as non-root user? According to this thread, there used to be an option UsePrivilegeSeparation, which is now deprecated: serverfault.com/a/861842 Oct 18 '21 at 12:04

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.

  • The manual says "If UsePAM is enabled, you will not be able to run sshd(8) as a non-root user.". I do expect the manpages do be correct.
    – Hermann
    Oct 17 '21 at 12:10
  • This is a general question not directed towards a particular distribution. You provided two examples which are indeed insightful. But what about any other distribution? If a Debian package manager changed the software's behaviour and did not update the man-page accordingly, we should probably file a bug. Moreso if this was changed upstream. If I started questioning man-pages and double checked on a daily basis, I probably would not get any work done.
    – Hermann
    Oct 17 '21 at 12:26
  • I just looked and found out this information is from 2004 and probably outdated. Will you file a bug?
    – Hermann
    Oct 17 '21 at 15:25

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.

Other opinions

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:


  • @zevzek feel free to edit my answer Oct 17 '21 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.