Skip to content
This repository has been archived by the owner on Apr 6, 2021. It is now read-only.

PAM reports: "Invalid verification code" #42

Closed
ThomasHabets opened this issue Oct 10, 2014 · 14 comments
Closed

PAM reports: "Invalid verification code" #42

ThomasHabets opened this issue Oct 10, 2014 · 14 comments

Comments

@ThomasHabets
Copy link
Contributor

Original issue 42 created by afrazkhan on 2011-02-23T12:44:13.000Z:

What steps will reproduce the problem?

  1. Install module as described in documentation, and add account to Android app
  2. Try to log into machine via ssh, GDM, or login command
  3. Enter username, password, and verification code from Android App
  4. Check /var/log/auth.log (in Debian / Ubuntu)

What is the expected output? What do you see instead?
Expect to login. Instead auth.log says "Invalid verification code".

What version of the product are you using? On what operating system?
No version number in source, but it's the one from 2011.02.23 at 12:00 GMT. Running Ubuntu 10.04LTS.

Please provide any additional information below.

Could this be to do with timezones? Does the application use the time in generating the verification codes?

If so, is there a way to specify the key as "counter based" instead of "time based" when generating it? I see that the Android application allows for both if you manually enter the key ID (instead of using the QR code).

@ThomasHabets
Copy link
Contributor Author

Comment #1 originally posted by afrazkhan on 2011-02-23T16:25:44.000Z:

Hmm, pretty sure it's a time related issue now. My phone's time was ahead by about 2 minutes.

The odd thing is that it didn't start working immediately after resetting the time. I re-imported the accounts I was testing several times, and something like half an hour later, it started working on all machines!

@ThomasHabets
Copy link
Contributor Author

Comment #2 originally posted by afrazkhan on 2011-02-23T16:28:24.000Z:

Hmm, this could be a time sync related issue. My phone's time was ahead by about 2 minutes. Not deleting the issue since I'm not convinced there isn't a bug here somewhere.

The odd thing is that it didn't start working immediately after resetting the time. I re-imported the accounts I was testing several times, and something like half an hour later, it started working on all machines!

@ThomasHabets
Copy link
Contributor Author

Comment #3 originally posted by robert.olejnik on 2011-02-26T19:06:41.000Z:

I have the same problem, but the time is correct (same values on my server and phone).

@ThomasHabets
Copy link
Contributor Author

Comment #4 originally posted by lionel.benson on 2011-02-26T21:07:17.000Z:

I also now having the same problem. Worked for about two days but now I have tried on three different machines but get the "Invalid verification code". I have ensured my machines are in "time sync" with my phone to the last second.

@ThomasHabets
Copy link
Contributor Author

Comment #5 originally posted by zodiac on 2011-02-27T03:21:00.000Z:

The application uses time since the beginning of the epoch (i.e. midnight, January 1st, 1970). Epoch's are defined as UTC. So, this should always be independent of timezones.

But yes, time skew can very well be a problem. You only have a window of about +/- 45 seconds to log in. If the phone and your computer don't agree on time, this won't work. I am working on a change that will allow you to specify a bigger window.

If you keep seeing this problem after ruling out misconfigured time, it would help to collect as much data as possible.

At the very least, it would help if you included exact time stamps as shown both by your server (use "date -u") and your phone. Also, include the code that you tried entering, and the contents of your configuration file.

If you file uneasy about publishing the configuration file in a public forum, feel free to regenerate it afterwards. If you do that, then please also let us know whether regenerating a new key fixes your problem.

@ThomasHabets
Copy link
Contributor Author

Comment #6 originally posted by lionel.benson on 2011-03-03T17:24:23.000Z:

Today I solved my "Invalid verification code" problem. I am definitely not that savvy on tech issues but this is what I did.

  1. I tested again to see if I would get the invalid code warning - which I did.
  2. I went to accounts on my desktop: [account settings>2-step verification>How to receive codes>Mobile application] and removed my android phone.
  3. I un-installed the authenticator from my android phone (not sure if this is necessary both did it anyway).
  4. I re-installed the authenticator.
  5. I added back by android phone and went through the steps to turn it back on.

I tried it now a few times and it works! No more invalid codes.
Hope this helps others.

Looking back now, the only thing I can remember is that I once used the authenticator on a machine that the time was off. Even after correcting the time it never worked again on any of my machines. Only after the above steps has it now started to work. Maybe something got thrown off and could not be reset - I leave that for the tech gurus.

Also, after performing the above steps, it did not reset my pass codes for my other apps and all paper back up codes are the same(which is nice).

I'm happy now :)

@ThomasHabets
Copy link
Contributor Author

Comment #7 originally posted by markus@google.com on 2011-03-09T19:53:12.000Z:

I am closing this bug report for now, as it sounds that the problem went away.

If the problem re-surfaces, please re-open this bug report and try to collect additional debug data so that I can attempt to reproduce it. Don't hesitate to ask for advice, if you need help in collecting the data.

@ThomasHabets
Copy link
Contributor Author

Comment #8 originally posted by ilia.fischer on 2011-04-14T02:47:39.000Z:

The problem is reproducible when Automatic time update ("Use network provided values") is off. When switching it back to ON the codes are valid.

Login to GMail.
HTC Magic.
Rogers Wireless.

@jameshhx
Copy link

jameshhx commented Jun 2, 2017

So I had this exact same issue on a Scaleway box. The solution turned out to be updating the /etc/ssh/sshd_config to set PermitRootLogin yes. The default value for Scaleway boxes at the time was PermitRootLogin without-password.

@ThomasHabets
Copy link
Contributor Author

@jameshhx really? auth log said "Invalid verification code"?

@CodingKoopa
Copy link

I had this issue, and the solution was to enable the systemd-timesyncd.service service to fix my system time.

@BouchaaraAdil
Copy link

the same here, pam keep reports that error
Dec 19 16:46:16 ip-172-16-100-124 openvpn(pam_google_authenticator)[8922]: Invalid verification code
using this configuration on etc/pam.d/openvpn

account required pam_unix.so
account required pam_permit.so
auth requisite pam_google_authenticator.so secret=/etc/openvpn/google-authenticator/${USER} user=gauth forward_pass
auth required pam_unix.so use_first_pass

and openvpn server
plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so openvpn
on client auth-user-pass

info about package version

yum info google-authenticator
Loaded plugins: priorities, update-motd, upgrade-helper
Installed Packages
Name        : google-authenticator
Arch        : x86_64
Version     : 1.0
Release     : 1.2.amzn1
Size        : 63 k
Repo        : installed
From repo   : amzn-main
Summary     : One-time passcode support using open standards
URL         : http://code.google.com/p/google-authenticator/
License     : ASL 2.0
Description : The Google Authenticator package contains a pluggable authentication
            : module (PAM) which allows login using one-time passcodes conforming to
            : the open standards developed by the Initiative for Open Authentication
            : (OATH) (which is unrelated to OAuth).
            :
            : Passcode generators are available (separately) for several mobile
            : platforms.
            :
            : These implementations support the HMAC-Based One-time Password (HOTP)
            : algorithm specified in RFC 4226 and the Time-based One-time Password
            : (TOTP) algorithm currently in draft.

Available Packages
Name        : google-authenticator
Arch        : i686
Version     : 1.0
Release     : 1.2.amzn1
Size        : 31 k
Repo        : amzn-main/latest
Summary     : One-time passcode support using open standards
URL         : http://code.google.com/p/google-authenticator/
License     : ASL 2.0
Description : The Google Authenticator package contains a pluggable authentication
            : module (PAM) which allows login using one-time passcodes conforming to
            : the open standards developed by the Initiative for Open Authentication
            : (OATH) (which is unrelated to OAuth).
            :
            : Passcode generators are available (separately) for several mobile
            : platforms.
            :
            : These implementations support the HMAC-Based One-time Password (HOTP)
            : algorithm specified in RFC 4226 and the Time-based One-time Password
            : (TOTP) algorithm currently in draft.

@AkshayaAnil
Copy link

AkshayaAnil commented May 10, 2019

Folks,
Check if SELINUX is enforced !. Disabling the SELINUX should solve it. If disabling is not an option for you, this can be still sorted out by creating some SELINUX policies , so that sshd process has proper privileges to work with the google authenticator. Below are the steps.

  1. make sure to have selinux policy devel installed.
  2. create alias for the make file ; alias semake='make -f /usr/share/selinux/devel/Makefile'
  3. create a directory of your choice , and within the directory create a file ending with .te; name it on your choice.
  4. create the selinux policies (have the below content added to the .te file that has been created in the above step)
    #give the module name you wish, it is good practice to have it named

similar to the policy file name

module sshd_ga_custom 1.0;

require {
type admin_home_t;
type sshd_t;
type user_home_dir_t;
class file { create getattr open read rename setattr unlink write };
}

#============= sshd_t ==============
allow sshd_t admin_home_t:file { create getattr open read rename setattr unlink write };
allow sshd_t user_home_dir_t:file { create open read rename setattr unlink write };
5. save the file.
6. compile the file by tying semake.
7.if it successfully compiles, you should see a file generated with extension .pp.
8. install the policy to selinux
semodule -i sshd_ga_custom.pp
9. restart the sshd service.
10. Boom ! you should be ON. hope it helps !

@BouchaaraAdil
Copy link

@AkshayaAnil i moved the vpn to ubuntu, it worked smoothly 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants