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

ssh

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?

Best Answer

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".

Related Solutions

Linux – sshd: How to enable PAM authentication for specific users under

You could probably handle this with the pam_listfile module. Create an /etc/pam.d/sshd file that looks something like:

auth requisite  pam_listfile.so item=user sense=allow file=/etc/authusers
auth sufficient pam_securid.so
auth required   pam_deny.so

This would allow only people listed in /etc/authusers the ability to authenticate with a two-factor module (in our case, secureid). I haven't actually tested this configuration, but the theory is sound.

You could make it simpler by allowing anyone to authenticate using two factor authentication; presumably, only those people with the appropriate devices/configuration would be able to succeed, so you'd get effectively the same behavior.

SSH Keys – Add Correct Host Key in Known Hosts for Multiple SSH Host Keys

get the rsa key of your server, where server_ip is your server's IP address, such as 192.168.2.1:

$ ssh-keyscan -t rsa server_ip

Sample response:

# server_ip SSH-2.0-OpenSSH_4.3
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...

and on the client, copy the entire response line server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG..., and add this key to the bottom of your ~/.ssh/known_hosts file:

server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)

Best Answer

Related Solutions

Linux – sshd: How to enable PAM authentication for specific users under

SSH Keys – Add Correct Host Key in Known Hosts for Multiple SSH Host Keys

Related Topic