Oh, and "Your control master connection will persist in the background after your initial client connection terminates, according to the value of ControlPersist". If that means that shutting down a laptop loses the connection that's not good enough – it means that the lifetime is less than the minimal acceptable one week.

I just checked and more than half of the files in user .ssh directories named id_rsa (default name for an RSA private key) are not encrypted so this is not just a theory.  And this isn't even looking at private keys kept locally which I suspect have an even lower chance of being encrypted.  The reality is that private keys are not stored properly by all users and attackers are able to use this fact to steal credentials.  (I am actually surprised by the number of keys that do seem to be encrypted.  I would guess this rate to be higher than for other NCSA resources, although many resources are also moving to requiring 2FA so use of keys may be more limited in the future.)

Shutting down a laptop means there is no state on the server side to track any longer and a new authentication is needed to reestablish identity.  One would need to have something stored on the laptop which is what we are attempting to prevent by asking for a password and maintaining the "something you know" over reverting to "something you have."

I am curious - how does your setup work with SSH key passphrases?  Doesn't one need to re-type the passphrase at least once each time one logs in locally?  I am assuming there is nothing in place to cache SSH key passphrases across system shutdowns but perhaps I am wrong about that.

If one really wanted to work around the spirit of the 2FA requirement, one could simply create a Kerberos keytab file stored locally on their system and kinit using that file and then use GSSAPI credential forwarding without needing to type a password.  There isn't a way to block or differentiate this on the SSH server side nor on the Kerberos KDC. See the ktutil man page for more info on creating keytabs.

SSH public key plus Duo (with a very similar albeit somewhat simpler PAM hack) is the same approach I've used elsewhere for access to internal systems.

I agree with the theoretical concern that this isn't a true second factor since the SSH key and the Duo authenticator are both things you have, but I would not weigh the classes of factor analysis too heavily. It's intended as shorthand to try to guide a security policy towards defending against more threats. In practice, Duo push plus an SSH public key requires that an attacker control two separate devices to directly bypass the authentication step, one of which (the phone for Duo push) probably requires physical theft, which is a high bar. There is some theoretical benefit of protection against stolen devices in scenarios where one believes a laptop and an unlocked phone may be stolen together, but in terms of risk modeling, I think it's around the edges.

Under either setup, the most likely attack is attacker compromise of the laptop followed by piggybacking on any open connection or available credentials, which works nearly as well with both password and SSH public key. ControlMaster makes this attack easier to perform and removes any marginal benefit of password over SSH public key against that attacker, so if you're willing to accept the risk of ControlMaster, I'm dubious accepting SSH public keys instead of passwords adds much additional risk.

Password plus Duo is slightly more secure (in that it protects against a few more attack paths) than SSH public key plus Duo, but I think it's a fairly minor benefit for the usability loss. The good news is that we have the luxury of knowing that the only attractive attack target for most attackers is abuse of resources; the data isn't very sensitive or of much attacker interest, so we're unlikely to attract a sophisticated attacker who would be willing to do things like compromise phones or use targeted malware.

posted and finished.