Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using two-factor authentication for SSH

arm-blog.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Using two-factor authentication for SSH

#41

Post by lrvick »

lrvick wrote: post #40
newman314 wrote: post #39

Using 2FA is all well and good but what I haven't found is a good solution for managing ssh keys for an organization/group. Would love to get some recommendations here.

I tend to store authorized ssh public keys in a database then configure all servers with the appropriate AuthorizedKeysCommand in sshd_config to fetch them on the fly. I also tend to include some form of caching in case the connection to the database is broken. With this I can maintain keys for an entire cluster centrally. This is all in place with open source configuration and tooling on https://hashbang.sh ( https:…

Worth noting: In both cases all keys with admin access are in fact GPG Authentication subkeys stored in smartcards each admin carries on their person.

Re: Using two-factor authentication for SSH

#42

Post by CaptSpify »

yeukhon wrote: post #38
CaptSpify wrote: post #30

Earlier quoted context omitted.

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

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

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.

Re: Using two-factor authentication for SSH

#43

Post by lwf »

lrvick wrote: post #37

There is already a standard solution for this imo. Get a GPG smartcard like a Yubikey and put an Authentication subkey on it. Now to ssh to anything, clone from Github, etc you insert your Yubikey, and enter your pin to unlock it. A gpg-agent process is created that acts as a standard ssh agent. No server modifications required and you get strong hardware backed 2FA. The ssh private key never enters system memory and…

Sure, SmartCards are two-factor, unless the token has a hardware/software bug.

This has happened in the past[1]. I'm a huge fan of the CCID/GPG capabilities of the YubiKey, but I'm not sure they should be used in isolation in high-security environments.

[1]: https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...

Re: Using two-factor authentication for SSH

#44

Post by cornelinux »

Not sure if to use SSH keys? Or Yubikey? Or Google Authenticator? On a whole bunch of machines?

Why not have it all?

Using privacyIDEA [1] you can

* manage SSH Pub keys for several servers * manage your Google Authenticator centrally * manage Yubikeys centrally or whichever OTP token.

In addition you can combine it to use the Google Authenticator or any other OTP ++PLUS++ SSH keys [2].

[1] http://privacyidea.org [2] https://www.privacyidea.org/ssh-keys-and-otp-really-strong-t...

Re: Using two-factor authentication for SSH

#45

Post by superuser2 »

Freak_NL wrote: post #35
superuser2 wrote: post #28

Earlier quoted context omitted.

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.

There is a crucial difference here. With FIDO U2F I am not limited to Yubico's offerings; there are other vendors. FIDO U2F devices can be manufactured by any company (and are). I agree that the ideal situation would be a device that is completely under the control of the user, but compared to IOS or Android, a hardware token that only does what it is supposed to do (in the case of the U2F tokens; register and sign a…

That's not a difference. You are also free to choose among many different smartphone manufacturers and OSes, all of which are capable of running a TOTP app.

Re: Using two-factor authentication for SSH

#46

Post by lrvick »

lwf wrote: post #43
lrvick wrote: post #37

There is already a standard solution for this imo. Get a GPG smartcard like a Yubikey and put an Authentication subkey on it. Now to ssh to anything, clone from Github, etc you insert your Yubikey, and enter your pin to unlock it. A gpg-agent process is created that acts as a standard ssh agent. No server modifications required and you get strong hardware backed 2FA. The ssh private key never enters system memory and…

Sure, SmartCards are two-factor, unless the token has a hardware/software bug. This has happened in the past[1]. I'm a huge fan of the CCID/GPG capabilities of the YubiKey, but I'm not sure they should be used in isolation in high-security environments. [1]: https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...

Facebook, Google, and the DOD all rely on yubikeys now to mitigate a lot of remote attack vectors. It is not perfect, but it is well audited by some of the best in the industry and as good as it gets atm. There has never been a situation where a yubikey (or other GPG smartcard) has allowed read access to private keys. The secure elements do their job.

As for this vuln, it was a flaw in pin validation, the secrets were never exposed. An attacker that has physical access to the system using the yubikey could simply wait and intercept the pin without this flaw. Any active agent no matter how it was initiated is subject to hijacking like this.

The pin protects against use when physically stolen, not when in active use by the owner. You get assurances your secrets are never copied, but no assurances they are not being used right in front of you by a third party on a machine you think is trustworthy.

The only way I know to mitigate an attacker hijacking keys like this without significantly inhibiting workflow is configuring automatic ejection and re-enumerate the device on touch. Then ssh talks to gpg agent which blocks and waits on key insertion. You touch it and it completes the ssh handshakes then it auto ejects the moment the operation is over.

Re: Using two-factor authentication for SSH

#48

Post by matthiasb »

jimktrains2 wrote: post #23
matthiasb wrote: post #21

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.

I work for Gemalto as a Sales Engineer... Smart cards and readers is what I talk about every day! May I recommend our smart cards? :D Please reach out to me by email.

Re: Using two-factor authentication for SSH

#49

Post by lwf »

lrvick wrote: post #46
lwf wrote: post #43

Earlier quoted context omitted.

Sure, SmartCards are two-factor, unless the token has a hardware/software bug. This has happened in the past[1]. I'm a huge fan of the CCID/GPG capabilities of the YubiKey, but I'm not sure they should be used in isolation in high-security environments. [1]: https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...

Facebook, Google, and the DOD all rely on yubikeys now to mitigate a lot of remote attack vectors. It is not perfect, but it is well audited by some of the best in the industry and as good as it gets atm. There has never been a situation where a yubikey (or other GPG smartcard) has allowed read access to private keys. The secure elements do their job. As for this vuln, it was a flaw in pin validation, the secrets wer…

> Facebook, Google, and the DOD all rely on yubikeys now to mitigate a lot of remote attack vectors.

Yes, but not as the sole factor. I've overseen a rather large deployment of Yubikeys, and I believe they provide a huge security improvement compared to other second-factor alternatives.

> The only way I know to mitigate an attacker hijacking keys like this without significantly inhibiting workflow is configuring automatic ejection and re-enumerate the device on touch.

Agreed. I was very happy when this was added in the YubiKey IV.

Re: Using two-factor authentication for SSH

#50

Post by nickik »

beagle3 wrote: post #33
nickik wrote: post #6

Earlier quoted context omitted.

You can use Yubico OTP as you 2 Factor for SSH. As far as I know you can not use U2F as a 2 Factor over SSH because it needs support from OpenSSH (or whatever). A patch does exist, however, it is not yet upstream (any information on this welcome). However in the absence of U2F, you can still use Yubico OTP (HOTP) or you can use your yubikey together with your smartphone for TOTP. I think its a bad idea to use your sm…

How does the yubikey hard drive encryption work?

Well the encryption is just standard luks. You can do it 2 ways (or 3 if you want to be fancy).

The simplest way is just to do a long static password and combine it with your normal password. So you type '1234' and then hit the yubikey button. The problem with this is that temporary access to your yubikey allows somebody to steal your static password.

The better way is to use the Challange-Response mode that send your password, the Yubikey sends back a hash (HMAC-SHA1).

Their is very new way that you can use that uses time based authenication, but this was just presented at 32C3, see: Beyond Anti Evil Maid [32c3]

Post reply on HN