Reinstating the ssh_google_auth-variable.

[dennisse]

This was removed in bea269a. Just because I use pam, and challenge response authentication, does not mean I wish to install libpam-google-authenticator.

[rndmh3ro]

Just because I use pam, and challenge response authentication, does not mean I wish to install libpam-google-authenticator.

You're right here, so I think we should remove the three google-specific tasks (https://github.com/dev-sec/ansible-ssh-hardening/blob/master/tasks/2fa.yml#L2-L20) instead of re-introducing the specific google variable. What do you think?

[dennisse]

I could get behind that. But then, why not just remove the whole 2fa.yml-file? I'm not sure why I would want to remove common-auth from my PAM-config when I've set both ssh_use_pam and ssh_challengeresponseauthentication to True (which is when the 2fa.yml-file is included).

[rndmh3ro]

But then, why not just remove the whole 2fa.yml-file? I'm not sure why I would want to remove common-auth from my PAM-config when I've set both ssh_use_pam and ssh_challengeresponseauthentication to True (which is when the 2fa.yml-file is included).

We probably need to rethink this whole 2FA-setup. Do you have experience with this and can provide some hints or code?

[dennisse]

We probably need to rethink this whole 2FA-setup. Do you have experience with this and can provide some hints or code?

Personally I use oathtool and libpam-oath (OATH-Tool), set up like this, which works pretty well. Amongst other things, it lets me decide from where 2fa is required (so I don't have to use it from well-known IP-addresses, which can be handy if you lose your token).

I would be willing to write this up in ansible for Ubuntu (Debian will probably work with the same setup), but I have little to no experience with the other systems you support.

However, for me, 2fa on ssh is an edge-case not really worthy of automation. Password-protected ssh-keys and whitelisting IPs is a lot more practical than these tokens. I only use 2fa where I absolutely cannot force ssh-keys.

[dennisse]

Made any decisions yet? :)
I'm still for just removing 2fa. Technically it doesn't have much to do with openssh. You just set up ssh to support a challenge response, and then 2fa is handled by pam.

[rndmh3ro]

No decision yet, but you're right, we should remove 2fa:

• no good support from us
• only configures pam, not ssh - so not suitable for this module
• required sshd-changes can be done with sshd_custom_options

Do you want to update this PR to delete the code?

[dennisse]

I'm thinking this might belong in a separate PR :) I'll create a new one asap.

[chris-rock]

Would making this feature opt-in an alternative to complete removal?

[dennisse]

I want to say no (not that it is my decission :)).
As I mentioned earlier, 2fa doesn't really have anything to do directly with ssh. 2fa is handled by PAM and other tools (libpam-oath, google-authenticator-libpam, etc). SSH only needs to support it, and this role already does so.

In my opinion, 2fa belongs in a PAM-role, or a separate role.

[chris-rock]

Great point. Is there a good pam role available that does the job?

[dennisse]

Not that I know of, no. But I guess 2fa could be moved to https://github.com/dev-sec/ansible-os-hardening as an opt-in feature. 2fa could belong in an os-hardening role.

As mentioned earlier:

for me, 2fa on ssh is an edge-case not really worthy of automation. Password-protected ssh-keys and whitelisting IPs is a lot more practical than these tokens. I only use 2fa where I absolutely cannot force ssh-keys.