Comment #1 originally posted by fuzzykiller on 2011-02-23T21:53:40.000Z:

The whole point of public key authentication, apart from added security, is not having to enter the password all the time. It bypasses the PAM auth. Use PAM account, if possible.

Comment #2 originally posted by Philip.Magalios on 2011-02-23T21:56:37.000Z:

Where I am, I want to be able to access 300+ servers with different passwords but with one key. I want to be able to use the google authenticator as a 2nd form of identification to make sure that if a private key has been compromised, there is still another layer of security that has to be gone through.

Comment #3 originally posted by fuzzykiller on 2011-02-23T22:05:19.000Z:

Like I said, someone suggested using the account stack of PAM, which is apparently used even with pubkey auth in OpenSSH. The purpose of this was to require a password even after successful pubkey auth. The auth stack is completely bypassed.

Comment #4 originally posted by Philip.Magalios on 2011-02-23T22:10:07.000Z:

I misunderstood your suggestion. I will investigate that. Thank you.

Comment #5 originally posted by Abubakar.Masood on 2011-02-23T22:26:00.000Z:

Where I am, I want to be able to access 300+ servers with different passwords but >with one key. I want to be able to use the google authenticator as a 2nd form of >identification to make sure that if a private key has been compromised, there is >still another layer of security that has to be gone through.

If you want to use the same key for all the logins, one way is to copy the .google-authenticator file to ur home directories and setting up pam to use google-authenticator on those machine. And the same key for all of the logins should work as long as you have the time synchronized between your cellphone and all the computers.

Comment #6 originally posted by markus@google.com on 2011-03-09T21:37:02.000Z:

Getting PAM authentication to work in SSH can be tricky (tell me about it :-) And it depends a lot on both the choice of SSH server and any local patches that a distributor might have applied to the server.

While we would certainly like to document recipes that are known to work, there isn't really much we can do to enable better PAM support in SSH per se.

You would probably have to instead file a bug with your vendor and/or with the upstream SSH project of your choice, if you cannot find a way to activate PAM support. And yes, I do understand why this is a complicated challenge for implementors for SSH servers. The SSH protocol isn't a great match for PAM.

I am closing this bug for now, as I don't think there is anything we can do on our side. But if you have a concrete suggestion of what we could do to make your life easier, please do not hesitate to re-open the issue and/or to file a new one.

Comment #7 originally posted by mbrevda on 2012-08-09T10:00:08.000Z:

How about allowing Authenticator to run as a shell or app, in addition to pam?

Shell mode: A user can be set up to use GA as its shell, promoting him for a OTP and then starting a real shell, or logging the user off - respectively.

App mode: run the app immediately when the user logs in, logging them off if they dont authenticate.

As a side note, it seems the RHEL shipped a patch in 6.3 that can require multiple forms of authentication, potentially resolving the issue here (for those on the latest RHEL/CentOS anyway). http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.3_Release_Notes/authentication_interoperability.html#id2801940

Comment #8 originally posted by mengesb on 2012-12-21T08:53:07.000Z:

Wow, indeed this is somewhat scary.

In our org, we have password protected private keys... but supposing IF someone got into my Linux desktop after I've already opened my keyring, now the user can get ANYWHERE without re-authenticating in any way. I wanted to setup google-authenticator to challenge an authorized share key; having two-factor (one key based, one challenge based) was very ideal, but this is a VERY MAJOR BUMMER that I have to 'ssh -o PubkeyAuthentication=no -p @' to see the fruits of my labor installing google-authenticator.

With public keys and two-factor, an intruder would now have to have my key (session unlocked or not) AND my authenticator (in my case my phone)... very unlikely to have both.

RE: running as a shell or app - there are exit methods to shove it background or exit past in most scenarios... once you have an established session if you can do the right things, you can break out.

Is this really a PAM issue?

Comment #9 originally posted by sampo.niskanen@mwsoy.com on 2013-03-08T12:23:37.000Z:

OpenSSH 6.2 (due in the near future) will provide the option of multiple mandatory authentication methods, which should make it possible to require public key + google authenticator.

https://bugzilla.mindrot.org/show_bug.cgi?id=983
http://www.gossamer-threads.com/lists/openssh/dev/55076 (bullet # 4 in new features)

Comment #10 originally posted by b.tiru.naidu on 2014-04-15T12:12:14.000Z:

Is this issue resolved? I used authy from authy.com and that worked out of the box along with pub key authentication. I really wanted to use google authenticator but this issue is somewhat stopping me from switching over.

Comment #11 originally posted by hugues@betabrand.com on 2014-05-22T02:52:42.000Z:

It is possible with OpenSSH 6.2 to use public key + PAM (i.e. google authenticator)

read the man page for sshd_config and look for AuthenticationMethods

This page here is also a very good source of information: http://lwn.net/Articles/544640/

Comment #12 originally posted by hugues@betabrand.com on 2014-05-22T02:53:15.000Z:

It is possible since OpenSSH 6.2 to use public key + PAM (i.e. google authenticator)

read the man page for sshd_config and look for AuthenticationMethods

This page here is also a very good source of information: http://lwn.net/Articles/544640/

Not sure I agree with the first comment, "The whole point of public key is not entering a password..."

The whole point of public key is that the private-key unlocking password never leaves the client system and that a breach of the public-key on the server does not result in a compromize of either the password (needed to unlock the private part) or the ability to discover the private-key.

Thus a breach is contained to a single server system, even if the keypair and/or key unlocking password is reused for other machines.

Now if you choose to increase your risk and reduce your security by keeping the unlocked private-key around on a system for a longer period of time that is upto you. Applications such as PuTTY Pageant can do this, although it maybe better if it was tied into the screen saver and/or smart card for better security.

However from this feature point of view, using GA with pubkey should be configurable. Some users will want both together and others will want pubkey only (but and password+GA together).

I found this issue as I am looking for pubkey&GA together to comply with current security regulations with using 2FA. It seems I have to go back to password authenticaiton to comply now as pubkey&GA together is not an off-the-peg configuration option.

This appears to be because SSH itself managed pubkey security and PAM manages GA.

I can only ask that 2 modules be written, the ability for SSH to understand 2FA (to maybe reuse existing PAM directly module) and the ability for PAM to understand pubkey.

Yeah that comment is weird. But it says "The whole point of public key authentication, apart from added security", so technically correct. The whole point is security and usability. :-P

OpenSSH does support pubkey+GA. See AuthenticationMethods in the manpage.

Sorry about the necromancy, but I think AuthenticationMethods doesn't sufficiently address the issue.

If you set AuthenticationMethods publickey,keyboard-interactive keyboard-interactive, you can log on using either GA+password, or publickey+GA+password, but not with publickey+GA (but not password).

AIUI, there is no way of requiring GA and any one of public key and password.

Either you configure sshd to accept publickey without a 2nd factor; or you tell it to require keyboard-interactive in addition to publickey, in which case what happens depends on your PAM configuration:

1. if pam_googleauthenticator is required, users with a public key get prompted for the OTP and their password.
2. if it is set as sufficient, users with no public key can log on with just the OTP, without specifying a password.

I'm not sure how best to address this. Maybe if ssh could be told to use a different PAM configuration for when a valid public key was presented?

Update: after some searching I found out about the SSH_AUTH_INFO_0 environment variable added in OpenSSH 7.8, which appears to do what we need. CERN wrote a pam_ssh_user_auth PAM module and a blog post on how to use it. I haven't tried it yet.

@akorn awesome, thanks for following up on this with links and solutions!