Using two-factor authentication for SSH
arm-blog.comThere 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 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,
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.
> 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.
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...
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.
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.
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.
> 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.
> 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.
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.
> A simpler and more robust method is SSH Keys + Passwords. I should write a blog post on this...
please do!
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.
Very Happy to see 2FA on SSH becoming more and more popular. One of the primary reasons my team has seen smart phones being used as the soft token is the ease of deployment argument, people already have the phone with them. With Yubikeys (not that they are cumbersome) but for some IT groups the "perceived" hassle involved (if a key breaks and have to reissue a new one) is a concern. You can lose your phone too, but some customers think that a phone has more chances of not being forgotten. We've also seen IT groups being quite comfortable using soft tokens because they have been using them for SaaS apps - whether its authy/GA or anything else, I guess familiarity kind of desenstizes the analysis of a risk vector.
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...
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 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...
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 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.
You can use yubi's PAM modules in conjunction with SSH PAM auth, no need to patch OpenSSH.
For Yubikey OTP, not U2F.
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]
Open source alternative to Yubikey (but with some features missing, such as NFC): https://www.nitrokey.com/
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?
The problem is that often you want to use your smartphone as a client to the same services. This essentially eliminates the second factor.
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.
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.)
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 authentication requests), and cannot be modified by the manufacturer after sale is very much preferable.
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.
I had the same question as you and the only thing I could think of was that our phones can be hacked too. It's a publicly facing device as well and has multiple vectors for attack vs. a standard dedicated 2F auth device.
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.
I recommend yubikey for everyone else. It's cheap, safe, simple, and widely used.
A far more simple solution is to require both SSH key and password. Something you have (a key) and something you know. You can even store your ssh key on a Yubikey, if you'd like.
I've been using Duo Security to add 2FA on SSH and other services on my SmartOS instances. It's really easy and the price is pretty low compared to the amount of work it would take to manage the keys and manual implementations.
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.
Authy provides something similar, I wonder if one is better than the other.
`authy-ssh` is much more advanced, but costs if you want over 3 authentications per day: https://www.authy.com/product/pricing/
I don't really understand authy: does it not keep your 2FA tokens in "the cloud" behind a password? Therefore, does this not make them equivalent to a password, and negate the whole point of 2FA?
I believe that functionality is opt-in (or a very prominent opt-out process), but yes I would say you no longer "have" the key, but are turning it into "knowing" a password required to retrieve the key.
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.
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://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.
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.
I prefer SSH keys with passwords + knocking for the ssh port (!= 22).
What about when someone steals your key from memory and observes your knocking sequence?