Google authenticator / SSH: multiple shared secrets per user & sharing of shared secrets over users

Question

I would like to add Google's authenticator app to our SSH authentication toolchain, as described in this article

However, it seems that the PAM module basically makes a hard link between "linux user" and "authentication user". This causes the following 2 problems for us:

• If we have multiple users on the system (for multiple different purposes), it is hard (impossible?) to share the google authentication method (TOTP shared secret) between them.
• If multiple real people want to log in on the same linux user, this forces us to share the secret among the real users.

In the standard SSH approach, where any real person's key can be added to any given linux user's authorized_keys, these problems are not applicable. How do I create the equivalent in the Google-pam setup?

Answer 1

Shared accounts do not work well with 2-factor authentication, as 2fa generally exists to prove that a user is who they say they are. Instead of shared accounts you should be using roles or user switching: someone connects with their own credentials as their own account and then performs a sudo operation to become a shared account. This has multiple benefits, including much improved auditing capabilities.

I do not believe you can make PAM work the way you want it without creating a shared secret that you give to all your users -- and even then you will have trouble when people will be locked out due to token reuse (e.g. userA connects and uses token 555555, then userB connects at the same time and tries to use the same token 555555, which fails because it's already been used once). I believe you can allow token reuse in stock google authenticator, but that basically negates the whole "one-time" part of "OTP".

Answer 2

There is a way you can distinguish the human during login process and although have all 5 humans use the same "root" account.

Of course the PAM module has its limits at this point.

But you should take a look at privacyIDEA. This project of mine lets you manage any kind of tokens (also TOTP, HOTP Google Authenticator, Hardware token, yubikey...) and assign these tokens to users.

Now there are two possibilities:

A) You may assign several tokens to the user root. And you know which token was handed to which human. On the server you install a privacyidea pam module, which authenticates against the privacyidea server. privacyidea determines which token was used to authenticate as user root and logs this in the digitally signed audit log. Thus you can deduce, which human logged in.

B) Every human has its own user account in privacyidea. You assign a token to each user account and hand over this token to the human. Now you can assign "remote" tokens to the root user. Thus the user root gets some kind of virtual tokens which link to the real tokens of the human users. When a user "root" authenticates you get the information about the virtual/remote token and the realm user's token in the audit log. Thus you directly see which human logged in as user root.

Shared Accounts is a bad idea

It is stated that shared accounts is a bad idea. I would upvote this statement. Avoid shared accounts! But sometimes it might be really difficult to avoid shared accounts. So the question is, what is the bad thing about shared accounts. And if we can mitigate this bad of shared accounts, shared accounts might not be that evil anymore.

I guess on big bad thing about shared accounts is, that you can not distinguish which human being logged in and performed the actions. So if you have a possibility to differentiate which human logged in as shared_user_A, then the problem might not be that big anymore. In this case 2FA is a good possibility, because you can identify which 2nd possession factor was used to login to the shared account. And if you can match the serial number of the possession factor to the human, then you are relatively clean again.

In your SSH scenario you might want to combine ssh keys (in authorized keys) with the shared TOTP Google Authenticator. A human has to have both, a unique ssh key (by which you might identify the human) and a shared TOTP.