Using two-factor authentication for SSH(arm-blog.com) |
Using two-factor authentication for SSH(arm-blog.com) |
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 could not be stolen even by an untrusted machine.
If the smartcard itself is stolen, it will brick itself on 3 incorrect pin attempts.
The same device can also store all your OTP tokens or behave as U2F depending on what a service supports so the end game is secrets no longer live on disk or in memory on your systems.
This also integrates well on Android devices via the Yubikey Neo with apps like Yubico Authenticator and Open Keychain,
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...
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.
A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this...
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.
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.
You can use ssh-agents for this. Some people consider that cheating though |;)
please do!
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...
Alternatively, you could go for a dedicated hardware token such as Yubico's FIDO U2F [1] keys [2]. Hardware tokens that use the fledgling FIDO U2F standard can also be used with PAM and SSH as well [3].
Two U2F keys (one backup) will cost around $40, and can be used with a growing number of webservices, including GitHub, DropBox, and GMail as well. The small form factor means you can put the key on your (physical, real world) keychain.
1: https://fidoalliance.org/specifications/overview/
2: https://www.yubico.com/products/yubikey-hardware/fido-u2f-se...
In theory I could worry about Duo going down, but I also rely on other critical cloud services and do have other ways to access an instance in an emergency (and Duo supports fallbacks).
Simplicity can be deceiving. In this case I think leaving security to the pros is worth the tradeoff. I've previously relied on cloud services for secure user management and wasn't let down.
Still Zero-Knowledge, but no longer really 2FA.
I still us Authy for a lot of my keys because (1) I have that cloud function off and (2) the UI is better than GA IMHO.
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://github.com/hashbang). It is implemented with LDAP+sssd there. Feel free to pop in as we love discussing this stuff.
We have done similar with etcd as the backing database at my employer.
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 smartphone as a 2Factor. However, if you combine your smartphone with your yubikey (download "Yubikey Authenticator") you can use your smartphone simply as a time provider.
This has the added benefit that if you lose your phone, you can use any other phone/table to do the authentication. Google Authenticator does not support that feature, and Authy Cloud-based solutions are not for everybody.
I use my Yubikey in all 3 different ways. I use Yubykey+Smartphone if I have no other options. Yubykey as U2F were I can (Dropbox, Github, Google) and Yubikey OTP (HOTP) for some services that support that instead of U2F.
Additionally you can use the Yubikey to decrypt your harddrive with HMAC or Static Password.
I really hope OpenSSH (and everybody else) will support U2F soon, its so much better then bothering with the smartphone and typing stuff into your computer.
The problem also is that the smartphone can be hacked and opens a huge attack vector that you don't have with other systems.
Also, typing in stuff by hand is a general bother.
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.)
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.
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]
From a software freedom perspective, hardware tokens/smart cards are no better than smartphones.
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 authentication requests), and cannot be modified by the manufacturer after sale is very much preferable.