My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 32: PAM module Make two step verification optional
45 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----

Sign in to add a comment
Reported by, Feb 15, 2011
What steps will reproduce the problem?
1. Build, install, and configure pam module.
2. Configure pam module for user X.
3. Other user Y cannot login any more.

What is the expected output? What do you see instead?

User Y should be able to login without using two verification when the $HOME/.google_authenticator doesn't exist; this allows testing of two step verification without having to enable it for all users.

What version of the product are you using? On what operating system?

Debian. 9:77c50ff7b7fa.

Please provide any additional information below.

Feb 15, 2011
Sorry, somehow got the version information completely wrong. This is the latest hg version, 44:bd9e0af3a6d5. Running on Ubuntu maverick.
Feb 15, 2011
Just noticed this is a duplicate of  bug #27 .
Feb 16, 2011
Feb 16 11:47:37 inara sshd(pam_google_authenticator)[32378]: Failed to read "/home/gpgverify/.google_authenticator"
Feb 16 11:47:39 inara sshd[32374]: error: PAM: Cannot make/remove an entry for the specified session for gpgverify from

it should simply issue a pass if they don't have google_authenticator configured.

Note that this introduces an issue if you are also wishing to protect sudo with google authenticator, as the user can simply remove their .google_authenticator and it will let them in.
Feb 16, 2011
Hello Jeremy,

Presumably an intruder that wishes to gain sudo rights without the validator can simply run google-authenticator and rewrite .google_authenticator anyway. So this change doesn't change that.

Not sure what the solution is to the sudo problem. You could move the file to somewhere only root has write access (this would also solve bugs like #24), however the user still needs to be able to somehow update it too. Maybe only allow updates if the user authenticates first, like with passwd?

Brian May
Feb 28, 2011
#5 paul.devrieze
You can do a lot with pam files and how you handle failure. The main problem is that the pam module does not return any other status code other than PAM_SUCCESS or PAM_SESSION_ERR. The attached patch changes the system to issue  PAM_PERM_DENIED when the token is not matched, and PAM_CRED_UNAVAIL when the auth file does not exist and PAM_AUTHTOK_ERR when retrieving the secret fails because of a file-related error.
585 bytes   View   Download
Feb 28, 2011
Interesting approach taken in comment #5. A lot simpler then the approach taken in  bug #27 , although that patch goes further with the suffix= option.

Trouble is that normally it should be the project members (Google) that pick the best approach and merge it into the official source, unfortunately they don't seem to be interested any more. I haven't noticed any responses to any of these issues from Google. I don't know if it is possible to get write access to the code here, if not maybe we should be making an official fork?
Feb 28, 2011
Project Member #7
We're still interested and will look at the possible approaches. I promise :-)
Mar 9, 2011
 Issue 21  has been merged into this issue.
Mar 9, 2011
 Issue 18  has been merged into this issue.
Mar 9, 2011
 Issue 27  has been merged into this issue.
Mar 9, 2011
(No comment was entered for this change.)
Labels: libpam
Mar 23, 2011
As an alternative workaround, PAM is able to limit this to certain users, using something like this:

auth            [default=ignore success=1] quiet user notingroup secure
auth            required

I agree, though... the idea of needing a user to set up the authenticator before trying to use it is vital, or else this becomes something of a chicken/egg problem.
May 13, 2011
I like this idea:

auth            [default=ignore success=1] quiet user notingroup secure
auth            required

Solves chicken and egg problem and it also gives an opportunity to require the authenticator code for only a certain amount of users 

In my case i want ssh accounts ( at least the ones that can su to root ) to require authenticator, but still allow sftp without  the authenticator.

Jun 9, 2011
Hi All,

Pardon the extraordinarily ugly code but the basic idea is to return a more appropriate error from google_authenticator() than PAM_SESSION_ERR on every failure. Using this hell-ugly patch (it's 3am here) and:

  auth [success=ok authinfo_unavail=ignore default=bad]

the PAM module will require the verification code if and only if the .google_authenticator file exists (or alternate if location specified). I think this is preferable to the other methods specified as it uses the existing PAM famework; it has error messages for these sorts of situations. I'm not sure I've used the right ones in every situation (not a PAM expert!) but as I say, this particular ugly hack seems to be working for me.

HTH someone.

2.7 KB   View   Download
Sep 12, 2011
Regarding comment 5 and the associated patchfile:  when the patch is applied "make test" fails as a result:

Testing failed login attempt
pam_google_authenticator_unittest: pam_google_authenticator_unittest.c:196: main: Assertion `pam_sm_open_session(((void *)0), 0, targc, targv) == 14' failed.
Did not receive verification code from user

because the test does not match what the new return codes are.
Sep 13, 2011
I propose a PAM configuration option, eg:

auth     required nosecretfile-is-ok

see the attached patch file to implement this idea.

If this option is set, this says "it is ok to let a user login if they do not have a secret file" -- ie have pam_google_authenticator go ahead and return PAM_SUCCESS if the file does not exist.  If the file does exist (or if the option is not set) then the default is that all users have to enter an authentication code.

This solves the sudo problem, because the .google_authenticator file could be a requirement in the /etc/pam.d/sudo PAM file (ie, the option is not used), but not required for /etc/pam.d/sshd.  So a user could login initially to get their .google_authenticator file set up, yet they could not sudo until they do so.

This also avoids the gnarly PAM configuration issues in comments 12 and 13, which I could never get to work on SUSE 11.

Ranting now...  I consider the big IF block in google_authenticator() right after parse_args() to be extremely ugly code.  This whole chunk of code should be redone.  It should examine the return values of each routine called here individually, and kick back appropriate PAM return codes after each step.  If the user does not exist after get_user_name(), then return PAM_USER_UNKNOWN, and so on.
1.3 KB   View   Download
Sep 14, 2011
Followup on comment 15: I discovered that my code can be interrupted and bypassed with a control-D from the ssh session.  In my case the pam stack is verification code, password, kerberos password if necessary.  Two control-D's jump thru the first two items, enter kerberos password, logged in.  Sigh...
Sep 16, 2011
I confirm this patch works on Fedora 13. Excellent, thanks :-) Although it works fine, an error is still logged (in my case in /var/log/secure), is there anyway that can be avoided?

i.e. my test user mnash is not using the 2FA. 

Sep 16 16:22:18 cyclops sshd(pam_google_authenticator)[6940]: Failed to read "/home/mnash/.google_authenticator"
Sep 16 16:22:20 cyclops sshd[6938]: Accepted keyboard-interactive/pam for mnash from port 57907 ssh2
Sep 16 16:22:21 cyclops sshd[6938]: pam_unix(sshd:session): session opened for user mnash by (uid=0)

Nov 13, 2011
Ref: Comment 16
A blank verification code will bypass this patch
Dec 15, 2011
I believe the main complaint from this issue is now addressed in the head of tree. Administrators can now set the "nullok" option to allow having a non-existent secret file.
Status: Accepted
Sign in to add a comment

Powered by Google Project Hosting