Live data from Hacker News

Using two-factor authentication for SSH

arm-blog.com

21–30 of 50 posts

Re: Using two-factor authentication for SSH

#23

I am using smart card authentication for SSH, I documented it here: http://codebazaar.blogspot.com/2014/07/how-to-ssh-with-your-...

Which vendor do you use and do they support openSC? I was having a heck of a time finding a vendor for a cards and readers.

Re: Using two-factor authentication for SSH

#24
post #3
post #2

If you have public-facing SSH daemons running, adding 2FA seems sensible. Google Authenticator essentially turns another computing device (the smartphone) into an ersatz hardware token. While this does increase security, I don't like the trend of turning the smartphone into a universal second factor. Alternatively, you could go for a dedicated hardware token such as Yubico's FIDO U2F [1] keys [2]. Hardware tokens tha…

Aside from situations where high security is needed (which would necessitate a dedicated piece of hardware to be the 2nd factor), Why are you adverse to using a smartphone as the 2nd factor?

I don't own a smartphone, for one, but I could purchase one if it would benefit me. As it is though, I cannot justify the cost and the increased monthly expenses. But for the sake of argument; if I did own a smartphone, I wouldn't want to turn it into a sort of virtual keychain. I can buy three U2F keys for under €60, and have spares. Smartphones are a single point of failure — unless you are in the habit of collecting spare smartphones.

There is also the matter of control. At the moment there are only a handful of smartphones that run an OS that is not under the control of Apple, Microsoft, or Google (Ubuntu smartphones come to mind as an alternative). On the other hand, on a normal computer I can run a full free software stack. To me this seems odd. If I own a piece of hardware, I want to run an OS and applications I can legally modify and tinker with, especially if I use it as a security device. By using tools such as Google Authenticator I get sucked into this walled garden.

The behaviour of hardware tokens such as Yubico's U2F keys on the other hand is completely verifiable — mostly because they are quite simple compared to a smartphone.

(Aside from these personal views on software, I do have high security requirements as well for some services, where a dedicated hardware token is preferable, as you point out.)

Re: Using two-factor authentication for SSH

#25
post #13
post #11

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 shou…

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.

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.

Re: Using two-factor authentication for SSH

#26
post #13
post #11

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 shou…

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.

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.

Re: Using two-factor authentication for SSH

#28
post #3

Earlier quoted context omitted.

Aside from situations where high security is needed (which would necessitate a dedicated piece of hardware to be the 2nd factor), Why are you adverse to using a smartphone as the 2nd factor?

I don't own a smartphone, for one, but I could purchase one if it would benefit me. As it is though, I cannot justify the cost and the increased monthly expenses. But for the sake of argument; if I did own a smartphone, I wouldn't want to turn it into a sort of virtual keychain. I can buy three U2F keys for under €60, and have spares. Smartphones are a single point of failure — unless you are in the habit of collecti…

Hardware tokens are general purpose computers that have been locked down to the vendor's walled gardens. Yubikey is a JavaCard (in USB stick form factor) running some closed-source applets. There is a key that would allow you to load your own applets onto it but Yubico won't tell you what it is.

From a software freedom perspective, hardware tokens/smart cards are no better than smartphones.

Re: Using two-factor authentication for SSH

#29
post #11

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 shou…

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

Re: Using two-factor authentication for SSH

#30
post #29
post #11

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 shou…

> 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 on…

> 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 |;)

Post reply on HN