Comment #1 originally posted by nunojpg on 2011-01-15T18:10:16.000Z:

How does this work on the public key authentication scheme? That is because sshd also needs to read a file from your home directory, ~/.ssh/authorized_host.

Does it work?

Comment #2 originally posted by torqroll on 2011-01-16T02:09:30.000Z:

I believe you mean the authorized_hosts file. But this is a good point. SSH public key authentication has the same problem when combined with home directory encryption. That is, SSH public key authentication will succeed only if the home directory is already mounted due to a console login or some other session. Otherwise public key authentication fails, and the next ssh method is tried, which is usually password.

I suspect that one can actually make google authenticator work together with SSH password authentication by reworking the pam files so that the password is asked for first, so that when it succeeds the home directory is mounted, then the pam_google_authenticator module is run second and it will work correctly. Switching to this order is not completely trivial due to the way the pam scripts are set up in Ubuntu 10.04 using auth-common. There might be some concerns with ensuring the directory is not left mounted if the google authentication fails.

But even with the above reordering of the pam checks, Google authentication together with SSH public key authentication would still not work. That is, if you had a public key set up, and expected that to take the place of the password, so that you only had to enter the verification code, this would fail. Since there would be no password available, there would be no way to get the home directory decrypted for either the SSH public key authentication to proceed or the google pam module to proceed.

I'm beginning to think that the idea of encrypting the entire home directory is going to have many issues, and any fix for pam_google_authenticator would fix only that, and not other things.

Comment #3 originally posted by valient on 2011-01-18T07:41:35.000Z:

It is a shame that this doesn't work with ecryptfs out of the box, as I would think the people interested in using two-factor auth for logins would overlap greatly with those using encrypted storage.

On Ubuntu 10.10, I didn't have much luck getting google_authenticator to run after ecryptfs was mounted. It may be possible, but it was easier for me to modify the authenticator module's behavior to look in another location. Unfortunately, it needs to be able to create new files at the same location, so it can't be a shared "/etc/google_authenticator" directory. Since the system I'm testing on has only 1 account, I modified pam_google_authenticator to add a suffix to the home directory, etc "/home/foo.auth/.google_authenticator";

@@ -41,2 +41,3 @@
#define SECRET "/.google_authenticator"
+#define SUFFIX ".auth"

@@ -117,3 +118,3 @@
*pw->pw_dir != '/' ||

•  !(secret_filename = malloc(strlen(pw->pw_dir) + strlen(SECRET) + 1))) {
  

•  !(secret_filename = malloc(strlen(pw->pw_dir) + strlen(SUFFIX) + strlen(SECRET) + 1))) {
  

  log_message(LOG_ERR, pamh, "Failed to find home directory for user "%s"",
  @@ -124,3 +125,3 @@
  }
• strcat(strcpy(secret_filename, pw->pw_dir), SECRET);
• strcat(strcat(strcpy(secret_filename, pw->pw_dir), SUFFIX), SECRET);
  free(buf);

Comment #4 originally posted by valient on 2011-01-18T08:39:35.000Z:

It is a shame that this doesn't work with ecryptfs out of the box, as I would think the people interested in using two-factor auth for logins would overlap greatly with those using encrypted storage.

On Ubuntu 10.10, I didn't have much luck getting google_authenticator to run after ecryptfs was mounted. It may be possible, but it was easier for me to modify the authenticator module's behavior to look in another location. Unfortunately, it needs to be able to create new files at the same location, so it can't be a shared "/etc/google_authenticator" directory. Since the system I'm testing on has only 1 account, I modified pam_google_authenticator to add a suffix to the home directory, etc "/home/foo.auth/.google_authenticator";

-#define SECRET "/.google_authenticator"
+#define SECRET ".auth/.google_authenticator"

Comment #5 originally posted by markus@google.com on 2011-03-09T20:33:12.000Z:

While I would generally suggest to either adjust the PAM configuration files as described in comment # 2 (with all the drawbacks described in that bug), or to alternatively switch to whole-disk encryption, I realize that this is not necessarily possible for all users.

I will probably implement an option to specify an alternate path for the secret file, for users that require this feature.

Comment #6 originally posted by markus@google.com on 2011-03-12T02:50:45.000Z:

I just committed a change that allows administrators to specify an optional "secret=" argument for the location of the ".google_authenticator" file. The README file has a brief example of how to use this option.

Comment #7 originally posted by stuart.tener on 2013-07-22T11:03:10.000Z:

I read this entire thread and whilst I am happy to see enhancements to the Google Authenticator code to add functions like the "secret=" argument, I am curious if anyone is using Google Authenticator + Standard Password to login to an Ubuntu Desktop account?

If so, I am thinking it might be possible to create a PAM stack that would accept the regular password first (and thus be able to mount the encrypted directory) followed by the Google Authenticator code?

Stuart

Comment #8 originally posted by stuart.tener on 2013-07-22T14:24:01.000Z:

All concerned:

I actually tested a PAM stack (under Ubuntu) that worked nicely (I had it configured differently until today):

In the /etc/pam.d/lightdm file I simply added the Google Authenticator subsequent to the "@common-password" line, and that made the stack work with the Google Authenticator after all the normal password activities were done (inclusive of mounting my encrypted home directory)! :)

Thus the last two lines of my file look as follows hereupon now:

@include common-password
auth required pam_google_authenticator.so

I have not yet tested what happens if I enter a bad google code (does it dismount the encrypted home?) or with other pam.d stacks either.

Stuart