7 ms·

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 set

• n1000 11y ago
  > A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this... please do!
• zokier 11y ago
  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.
  • superuser2 11y ago
    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.
  • matt_wulfeck 11y ago
    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.
• yeukhon 11y ago
  > 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 11y ago
    > 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 11y ago
      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 11y ago
        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.
• peterwwillis 11y ago
  Here you go: RADIUS-enabled AD authentication of a VPN w/Google Authenticator 2nd factor. https://github.com/rharmonson/richtech/wiki/CentOS-7-Minimal-&-Two-factor-Authentication-using-FreeRADIUS-3,-SSSD-1.12,-&-Google-Authenticator 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.
• aiiane 11y ago
  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.
• Esau 11y ago
  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.