[georgyo]

The biggest problem with using google authenticator as a two factor mechanism is if you are managing many servers, is that each server needs to have its own setup. If they share keys, and one server gets compromised, they can generate keys for your other servers. As a result, you also cannot automated the process of deploying two factor on your servers.

A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this...

[peterwwillis]

Here you go: RADIUS-enabled AD authentication of a VPN w/Google Authenticator 2nd factor. https://github.com/rharmonson/richtech/wiki/CentOS-7-Minimal...

You can also set up an SSH CA to validate clients by signed certificates, making managing a farm and its users' keys much easier. Then you don't even need an auth server online.

[zokier]

Isn't that problem solved by using centralized authentication server instead of distributing the authentication material on individual servers? I imagine that would be best practice regardless of authentication method.

[matt_wulfeck]

Personally I find a yubikey to be the best middle ground. Your private key is stored in the secure element and can never be removed from the hardware. You protect that also with a password, and the key must be physically touched to be activated.

[superuser2]

Given the extremely bad consequences of the authentication server's failure and the load it might be under for a fleet of 1000s of servers, that would probably require a fairly sophisticated clustering/HA approach. That is a lot of effort to spend compared to writing ensure => present and ensure => absent for a bunch of SSH keys in Puppet, which anecdotally seems to be what a lot of major companies do.

[yeukhon]

> A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this...

Problem 1. Now you have to maintain password

Problem 2. Now you have to handle prompt. Some Cfg tools are capable but is quite painful for others, which means you can't automate 2nd auth. Actually you can automate like 2nd auth there are paid service out there offer API.

IMO, actually, better approach:

* each instance only allow coming from known network

* user must be authenticated and authorized with LDAP / added to authorized_keys file and enable SSH logging

* automation should retrieve the private key from some safe location and is constantly rotating key across instances. This is quite easy on AWS with IAM if you run infrastructure on AWS. For non-AWS, you just harden the location twice as hard.

[CaptSpify]

> Problem 2. Now you have to handle prompt. Some Cfg tools are capable but is quite painful for others, which means you can't automate 2nd auth. Actually you can automate like 2nd auth there are paid service out there offer API.

You can use ssh-agents for this. Some people consider that cheating though |;)

[yeukhon]

Sorry maybe I am not aligned, ssh-agent for handling password prompt? ssh-agent afaik is useful for going from A->B and then B carrying that over to C,D,E,F,G etc

[CaptSpify]

Maybe we're talking about different things then? If you use the agent, you only have to handle the prompt once, then it's cached. That's the automation I was replying about.

[aiiane]

This is why U2F is a superior alternative to pin-based 2FA and hopefully will eventually replace it - you can use a single U2F device as a second factor for many different servers without either sharing keys or requiring a bunch of different authenticator entries.

[n1000]

> A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this...

please do!

[Esau]

I didn't realize that you could make SSH use both keys and passwords. I like the idea of that; even if it isn't as robust as 2FA. Please write it up.