It is some kind of One TIme Password tool to allow you to add One Time Passwords to you Linux Login and I guess use your Android phone.
pam_google_authenticator causes login programs to try and write to ~/.google_authenticator by default. SELinux does not like this. SELinux prevents login programs from writing to random locations in the home directory. It is usually not a good idea to rely on stuff in the home dir for authorization because the homedir may require authorization to be able to be mounted or decrypted. (kNFS for example).
I got a bugzilla on sshd not being able to write to ~/.google_authenticator. One option would be to set the label on the .google_authenticator as ssh_home_t. I also did some "googling" and found the following entry:
http://code.google.com/p/google-authenti
Comment by phil.may <snip>, Jul 7, 2011
BTW I have not tried this out on Fedora 16, and am curious if this will work, or does pam_google_authenticator expect the contents of .google_authenticator to survive a reboot.If you are using Fedora and SELinux, you will need to use the right config. The default SELinux policy does not allow the SSH daemon to update the ~/.google_authenticator file.
In Fedora 14 (and possibly other versions) sshd runs under "sshd_t" and can only writelocations with certain SELinux labels. One such label is "var_auth_t" and the default policy sets this label on "/var/run/user/" Therefore, the following config works:
# If the user is NOT in group "otp_users", skip next module
auth [success=1 default=ignore] pam_succeed_if.so user notingroup otp_users
auth required pam_google_authenticator.so secret=/var/run/user/${USER}/.google_authenticator
auth include password-auth
2012-03-25 12:03 am (UTC)
I've tried adding both paths using semanage but found that still did not appear to resolve it.
As I use google authenticator mainly for SSH I simply moved the file into ~/.ssh/ after applying the change with
auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authen
the directory permission issues went away.
This was all tested on CentOS 6.x
Cheers,
Sam
I have fixed this problem in Fedora 17
2012-03-27 05:05 pm (UTC)