The question of how to do non-annoying multi-factor authentication for SSH

April 26, 2021

Suppose, hypothetically, that you have access to a general multi-factor authentication (MFA) system such as Duo (with the choice of MFA system not being under your control), and that you would like to use this for secure SSH logins to your collection of (Ubuntu) servers. This is generally easy by itself, with pretty much any MFA system having a PAM module that adds a second factor challenge to your regular SSH authentication. Unfortunately the result of a straightforward MFA integration with SSH logins is going to be quite annoying for some people to use, because every time they log in to any machine they will have to pass an MFA challenge as well as their regular login authentication. If you only log in to a few machines every so often, this is okay. If you're frequently logging in and out of multiple machines, you're going to be irritated.

(One consequence of this is that it encourages everyone to stay logged in to all of your machines all of the time. This is not necessarily what you want for good security.)

The general industry solution for this seems to be short term SSH user certificates that are issued through some MFA/SSO gateway; Smallstep has a writeup of this with links to other people who have done it. I have a number of questions about how well this works on Windows and how easy it is to teach people to use it (and to troubleshoot problems), plus you also have to run your own MFA/SSO gateway and signing infrastructure (which is critical both for security and for people being able to log in to any of your systems).

(I'm going to assume that Windows 10 has a decent SSH agent story these days. The SSH user certificate stories usually load your newly issued certificate into the agent, although that leaves me with other questions.)

The general simple solution seems to be putting the MFA somewhere other than SSH logins; common approaches are MFA VPNs and MFA remote desktop connections. You still require (single factor) authentication on SSH logins as usual, but you only allow them from MFA-protected sources instead of from anywhere (either the general Internet for people like us or an organizational intranet). This solution also lets you have MFA for SSH logins from outside a trusted area without forcing MFA for all SSH logins, which otherwise gets complicated with the MFA PAM module solution. The remote desktop solution has the drawback that people need a remote desktop at work to connect to.

The natural Unix and SSH expert solution is a variant of this. You have an MFA protected SSH jumphost and people establish a shared connection to it that they authenticate and let sit. With an existing connection master, they can run ssh in other windows and sessions and it will piggy-back on the already authenticated master connection to the jumphost, then pass onward to perform regular SSH authentication to the hosts past the jumphost. Your other hosts are not accessible via SSH except from the jumphost or the internal network. I'm not sure how well connection sharing works with current Windows SSH clients, and in general it's subject to issues if the single TCP connection has problems or is ever broken.

A less nice but easier to explain version of this is that people log in to the jumphost and start screen or tmux sessions there that they use to log in to whatever machines they want. This version is resilient against the person to jumphost connection being broken, but has the drawback that people who reasonably want to log in to different machines in different windows are faced with multiple MFA challenges.

It would be nice if there was some easy to use way that would get SSH on the clients to interact nicely with web based MFA SSO. How I'd like it to work is that if you already have a SSO authenticated browser session (which you probably do), your SSH clients transparently inherit this single signon without you having to do anything special. However, I don't think there are any such systems without additional software.

PS: In some high security environments, the answer is that every SSH login must be protected by MFA no matter what and that people will have to live with that inconvenience. This doesn't describe our environment, and if we tried to treat it that way I'm pretty certain we'd find people bypassing us in various ways.

Written on 26 April 2021.
« Maybe a local, on-machine caching DNS resolver should be standard (for us)
Firefox's slow takeover of the address bar's space »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Apr 26 22:57:04 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.