Two-Factor Authentication with SSH

http://sysconfig.org.uk/two-factor-authentication-with-ssh.html

by joshbaptiste • 11 years ago

88 41 11 years ago

sysconfig.org.uk

helper• 11 years ago

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

jaryd• 11 years ago

The push notifications and tap to accept (no transcribing 6 digit codes!) is game changing. +1 for Duo!

teraflop3• 11 years ago

Duo's PAM module arguably violates the "MFA is only useful, if all parts of it can be enforced server-side!" principle from this blog post. The authentication does happen on a server, but it's a server controlled by Duo, not by you. The PAM module simply makes an API request and authorizes a user iff Duo says they should be authorized.

(Hopefully you'll have configured things so that Duo's approval and a password are both required for login, so this isn't a catastrophic break in security, but it's still a little worrying. And what about when your Internet connection, or Duo's, is having problems? As I write this comment, HTTPS connections to www.duosecurity.com are throwing errors because they've installed a certificate for *.test.duosecurity.com. [1])

I prefer Google's pam_google_authenticator module. Like the Android/iOS app, it doesn't have any external service dependencies; all it assumes is reasonable clock synchrony.

[1] https://www.ssllabs.com/ssltest/analyze.html?d=www.duosecuri...

sterlingduo• 11 years ago

Sterling Windmill from Duo Security here. We experienced a brief issue today resulting from the deployment of an incorrect SSL certificate to our public website. One benefit of the conscious decision to segregate our public website from other services is that this event had no impact on end user authentication. Feel free to reach out to support@duosecurity.com with any questions regarding this or anything else!

uN8yahg• 11 years ago

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

JupiterMoon2• 11 years ago

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?

chrisper3• 11 years ago

You can disable the phone in the Duo Admin Portal.

blfr• 11 years ago

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• 11 years ago

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

zobzu2• 11 years ago

Found Mozilla's version https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Multi-F...

noinsight• 11 years ago

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.

zobzu2• 11 years ago

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

dagss2• 11 years ago

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• 11 years ago

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• 11 years ago

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.

task_queue• 11 years ago

A VPN will allow you to tunnel all of your traffic over a secure connection.

In SSH, you can tunnel ports, but that only secures traffic at that port. You can use a SOCKS proxy, but that only secures traffic configured to go through it. You can use the -w option and use IP forwarding, but then you're running TCP/IP over the SSH protocol which is bad. This is the closest you'll get to emulating what a VPN provides.

zaroth3• 11 years ago

I think the question is not, should you use SSH as a makeshift VPN, as that answer is more obviously "probably not". The harder question is, is it better to VPN in before connecting to SSH, and present MFA at the VPN and SFA at the server, or is it better to expose SSH directly and perform full MFA directly at the SSH endpoint?

What do you trust more, OpenVPN with a port forward to an SSH server behind it, or a directly exposed SSH agent? Which will properly authenticate users without exposing any possible auth bypass, RCE, DoS, side channels, or potential vulnerabilities?

In general it's best if you can assume a perimeter firewall (i.e. VPN) will not always succeed in keeping the bad packets out. Of course it's a cop out to simply say "do both".

In general if you are managing a larger number of servers, it's not practical to MFA to each one individually / interactively. So you are forced to MFA to the border, and SFA to the individual servers. If you have a small number of servers you may find you get more fine-grain control, better auditing, and fewer points of failure to do something like this article suggests -- skip the OpenVPN and implement fully server-side validated MFA directly to the server.

The ultra-paranoid would add an HMAC based port-knocking scheme and forget about primitives like fail2ban. This could either be based on a 3rd factor or reusing the existing private key.

MacsHeadroom• 11 years ago

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

nnx• 11 years ago

Duo Security looks nice - but don't you run the risk of getting locked out from your own servers if Duo is unavailable or suddenly closes down?

What's the contingency?

nav1• 11 years ago

The app still generates offline codes as a backup, iirc.

chrisper3• 11 years ago

You can either use offline (SMS) codes or you can configure that it allows you to connect without duo if the system is offline.

ryan-c3• 11 years ago

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• 11 years ago

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

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

yeukhon• 11 years ago

Duo's two factor auth can be bypassed by someone with access to Duo's systems. This is interesting... why?

KenanSulayman• 11 years ago

I'm using 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.

JupiterMoon2• 11 years ago

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.

epinards• 11 years ago

https://jumpcloud.com/blog/sharing-google-authenticator-secr... 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.

based2• 11 years ago

Another one https://www.rcdevs.com/products/tiqr/ https://tiqr.org/archives/353/

http://www.reddit.com/r/2fa

0x45696e6172• 11 years ago

Shameless self-plug:

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

https://turquoiseliquorice.wordpress.com/2013/10/05/three-fa...

ryan-c3• 11 years ago

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• 11 years ago

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

tmnt007• 11 years ago

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.

namplaa• 11 years ago

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

Two-Factor Authentication with SSH

Related Stories