
Using two-factor authentication for SSH - kn9
http://www.arm-blog.com/using-2-factor-authentication-for-ssh/
======
lrvick
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 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,

~~~
lwf
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...](https://developers.yubico.com/ykneo-
openpgp/SecurityAdvisory%202015-04-14.html)

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

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

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

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

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

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

------
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](http://privacyidea.org) [2]
[https://www.privacyidea.org/ssh-keys-and-otp-really-
strong-t...](https://www.privacyidea.org/ssh-keys-and-otp-really-strong-two-
factor-authentication/)

------
Freak_NL
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/](https://fidoalliance.org/specifications/overview/)

2: [https://www.yubico.com/products/yubikey-
hardware/fido-u2f-se...](https://www.yubico.com/products/yubikey-
hardware/fido-u2f-security-key/)

3:
[https://developers.yubico.com/pam-u2f/](https://developers.yubico.com/pam-u2f/)

~~~
9point6
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?

~~~
Freak_NL
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.)

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

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

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

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

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

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

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

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

------
PTRFRLL
Authy provides something similar, I wonder if one is better than the other.

[https://github.com/authy/authy-ssh](https://github.com/authy/authy-ssh)

~~~
Leszek
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?

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

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

~~~
lrvick
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://hashbang.sh)
([https://github.com/hashbang](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.

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

------
e40
I prefer SSH keys with passwords + knocking for the ssh port (!= 22).

~~~
lrvick
What about when someone steals your key from memory and observes your knocking
sequence?

