
Two-Factor Authentication with SSH - joshbaptiste
http://sysconfig.org.uk/two-factor-authentication-with-ssh.html
======
helper
We've been using Duo Security for two factor ssh auth[0] for a number of
years. Its quite easy to setup and gives you push notifications to your phone.
Its awesome.

[0]:
[https://www.duosecurity.com/docs/duounix](https://www.duosecurity.com/docs/duounix)

~~~
uN8yahg
Hi. I live in a dangerous city. What if I lost my phone?

~~~
JupiterMoon
Encrypt it? Don't store credentials on it unless you really need to? Make
rotating keys and passwords easy in the event of losing it?

------
dagss
From the article: "You should not publicly expose SSH on any server, if you
can avoid it! The vast majority of your estate would of course be locked away
and protected by some sort of proper VPN (IPSec, OpenVPN etc), wouldn't it?"

I'm curious about more details -- to what degree is SSH (with public key auth
only of course) more vulnerable than VPN, and for what reason? From academia
I'm used to access to computers around the world using public SSH and port
forwarding for most things, and in my world VPN was something people used on
Windows, or just because it lets desktop applications act more normally, but I
didn't think there was a security difference...

(Yeah I don't do sysadmin work, rest easy)

~~~
flurie
The author goes into this in the beginning by stating that the admin can have
"PasswordAuthentication no" in sshd_config and users with keys can still have
weakly protected (or unprotected!) keys.

In other words, you can lead a correct horse battery staple to water, but you
can't make it protect its key pair with a strong password.

~~~
gh02t
That's a separate issue though. You can have weak/unprotected VPN keys as
well.

I think the author's argument about using VPNs is more a "right tool for the
job" thing. SSH is fine for remote shell, but then you start to need other
network service access. You can use SSH tunneling, yes, but a VPN is better
suited.

So, in a nutshell, the point is "only expose a _single_ service." And since a
VPN is more flexible than SSH, might as well go with that if you have the
choice. You can of course make counter arguments along the lines of "expose
only the minimal amount of functionality" or whether you think a VPN or SSH is
more secure.

------
MacsHeadroom
The usability of Duo Security's SSH two-factor and PAM two-factor make Google
MFA look like an early beta of Microsoft Bob.

It's already in the most popular repos. It's used by the likes of NASA,
Facebook, Box, Arbor Networks, Internet2, Twilio, Yelp, etc.

[https://www.duosecurity.com/docs/duounix](https://www.duosecurity.com/docs/duounix)

~~~
ryan-c
Google Autenticator can't be bypassed by someone with access to Google's
systems. Duo's two factor auth can be bypassed by someone with access to Duo's
systems.

For what it's worth, I agree that Duo has better usability, and is probably
the better solution in most cases. TOTP is the more paranoid option.

~~~
w8rbt
I believe that Google Authenticator uses TOTP. Six digit HMAC-SHA1 TOTP from a
base32 encoded secret using a 30 second timestep. At least, that has been my
experience. I wrote an OATH client and it works with Google Authenticator
using those parameters.
[https://github.com/w8rbt/oathgen](https://github.com/w8rbt/oathgen)

Duo supports this as well (and also other TOTP/HOTP modes). If you have access
to a Duo account, look at the 'Import Hardware Tokens' feature under
'Devices'. That's not named accurately. Really it should be named, 'Import
TOTP/HOTP secrets' as that's what they ask you to import and those secrets can
be used in OATH compliant HW fobs or any software that does standard
TOTP/HOTP. They also allow you to import Yubikeys as well if you like (of
course, that's not OATH).

~~~
teraflop
TOTP relies on a shared secret. With Google Authenticator, the secret is
shared between your phone and the SSH server you're logging into. With Duo,
the secret is shared between your phone and Duo's API backend; the server has
no independent way of authenticating it.

------
blfr
_Now, some people argue that a password-protected SSH key pair consitutes MFA,
with the key pair being the "what you have" and the password protecting it
being the "what you know". Well, it is wrong and dangerous!_

No. It is fundamentally correct. The user can always do all kinds of stupid
things to undermine the security of services they can access. For example
transfer their token from a separate device (phone) to a generator on the same
computer they use to log in (there's even a Chrome addon somewhere), or store
passwords in a sticky on the screen... the possibilities are endless.

Still a good article on your MFA options with ssh.

~~~
ak217
Right, it is wrong and dangerous, but not for the reason the article claims.
The user can always do something stupid to compromise their security, but if
they just do what they're advised to do (store their token on their phone),
then with proper 2FA, the attacker has to compromise two systems (the computer
with the terminal and the phone with the TOTP secret) to gain access. With SSH
passphrases, only one system needs to be compromised (the terminal).

------
zobzu
Found Mozilla's version
[https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-F...](https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-
Factor_Authentication_.28OpenSSH_6.3.2B.29)

~~~
noinsight
That one seems to recommend the OATH-toolkit, I tried it once and the
documentation wasn't impressive (shocker!) and I was concerned about the
security aspect as well. I wonder if anyone has audited that code properly?

Google Authenticator PAM module seems to be the other option that is widely
used and it's much easier to find information on it.

~~~
zobzu
the oath toolkit seems more standard if you look at the code itself, google
authenticator code is pretty ugly in comparison

------
based2
Another one
[https://www.rcdevs.com/products/tiqr/](https://www.rcdevs.com/products/tiqr/)
[https://tiqr.org/archives/353/](https://tiqr.org/archives/353/)

[http://www.reddit.com/r/2fa](http://www.reddit.com/r/2fa)

------
JupiterMoon
What about when your users start storing their passwords in a password manager
app? Which is on both their smartphone and their laptop? (And it's possibly
only encrypted when they are logged out - i.e. hardly ever)

The point being that users are already turning something-you-know into
something-you-have by using a password manager.

EDIT I'm not saying that password managers are a bad thing.

------
tmnt007
We use fwknop (time-based, single-packet, single ip, port knocking with gpg
keys) + monkeysphere (ssh keys stored in gpg) + Google Authenticator on
FreeBSD with PF enabled in addition to Security Groups on AWS.

------
epinards
[https://jumpcloud.com/blog/sharing-google-authenticator-
secr...](https://jumpcloud.com/blog/sharing-google-authenticator-secret-keys-
across-servers/) If you are interested in setting up 2FA for SSH, we have a
great step-by-step guide for multi-machine deployments. Alternatively, you can
sign up for JumpCloud to automatically implement this, and manage other key
aspects of your infrastructure.

------
KenanSulayman
I'm using yubico-pam ([https://github.com/Yubico/yubico-
pam](https://github.com/Yubico/yubico-pam)) module for a bit over a year now
on our controlling servers as well as my own, so that we can use Yubikeys for
authentication. Works extremely well so far.

------
0x45696e6172
Shameless self-plug:

Three-factor authentication with ssh public key, Google Authenticator and
password

[https://turquoiseliquorice.wordpress.com/2013/10/05/three-
fa...](https://turquoiseliquorice.wordpress.com/2013/10/05/three-factor-
authentication-with-openssh-google-authenticator-and-password/)

~~~
ryan-c
That's still two factor authentication. The possible factors are "something
you know", "something you have" and "something you are". Two "things you have"
only count as a single factor between them.

~~~
CMCDragonkai
How do you authenticate something you are? Specifically across a medium like
the internet? Fingerprint scans?

~~~
ryan-c
Generally, "something you are" is some sort of biometric. Fingerprint, iris,
hand geometry, palm veins, face and voice are all possible. Some laptops have
fingerprint readers, face/voice recognition would probably work fine through a
cheap webcam. I'm not sure how you'd prevent replay attacks if you were
running it over the internet.

~~~
zaroth
For single or small-n user systems, the best practice that's evolved around
this is to not actually send the fingerprint image to the remote server. A
trusted security module has a private key and the biometric sensor, and the
remote server has the public key. The trusted security module locally
validates the fingerprint, and then signs a message that can't be replayed to
indicate the fingerprint was presented.

------
namplaa
I've found the biggest issue with most of the Google Authenticator
implementation is that they store the seeds in plain text.

