Example /etc/pam.d/login (excerpt): ---------------------------------------------- auth required pam_nologin.so auth required pam_unix.so nullok account required pam_unix.so password required pam_cracklib.so password sufficient pam_unix.so nullok md5 shadow use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.so session optional pam_ssh_agent.so ------------------------------------------------ In the above setting pam_ssh_agent fails Reproducible: Always Steps to Reproduce: 1. pick the above simple /etc/pam.d/login 2. attempt login at console 3. check any agents started Actual Results: no ssh-agent or gpg-agent started Expected Results: start ssh-agent and gpg-agent with the keys opened using the password provided at authentication phase What happens here is the following. pam_ssh_agent's proper place is in the session phase. The value of PAM_AUTHTOK however is not by default available in the session phase (only auth and password phase) thus pam_ssh_agent is unable to use the authentication token to open the keys. (btw the package pam_ssh solves this problem by decripting the keys in the auth phase, storing them and reusing the stored keys when the module is accessed again in the session phase). What's quite interesting about this bug (which made it very hard for me to spot it) is that the problem does not appear if pam_unix gets alled in the auth phase throught pam_stack: /etc/pam.d/login: [...] auth required pam_stack.so service=system-auth [...] /etc/pam.d/syste-auth: [...] auth sufficient pam_unix.so likeauth nullok auth required pam_deny.so [...] I tested it with a simple test pam module, which does nothing but queries PAM_AUTHTOK in the session phase. results: PAM_AUTHTOK is *not* available in the session phase if either: 1. pam_unix.so is directly put in say /etc/pam.d/login or 2. pam_unix.so is in say /etc/pam.d/system-auth and system-auth is *include*d from /etc/pam.d/login PAM_AUTHTOK *is* available in the session phase if pam_unix.so is in say /etc/pam.d/system-auth and system-auth and system-auth is *pam_stack*-ed from /etc/pam.d/login Miraculously, using pam_stack.so circumvents whatever mechanism blocks the authtoken for surviving the authentication phase
sorry, wrong bug
Either a configuration problem or something that should be taken care of by upstream.
