[kgilpin]

Most people we have worked with don't take ssh key passwords seriously, because they can be stripped out. We advocated for the idea that password-protected ssh keys are a form of 2-factor auth, but nobody bought into that.

Organizations that want 2-factor auth are typically setting up bastion / jump hosts that require a second factor like a phone-delivered one-time password. This can be configured through the PAM stack.

Once on the bastion, the user can get to other machines within the accessible network using their passwordless ssh key. In effect, each bastion serves as a mini-perimeter.

And yes, people spend a lot of time entering their second factor. Dozens of times per day is not unusual.

Re-reading your question, I'm not really answering it. But maybe this anecdote is useful in some way :-)

[jlgaddis]

> Once on the bastion, the user can get to other machines within the accessible network using their passwordless ssh key.

I really really hope that bastion host never gets compromised.

[jessaustin]

Well, sure, but that's inherent in the "perimeter" concept referenced above. The design assumes there is an advantage to relaxing the hardening requirements of hosts connected only to the subnet. These could include: only having to keep ssh whitelists current on the bastion, instead of on all hosts. Being able to completely reorganize reverse proxies without having to update all the app servers. In general, it can be valuable for any particular host to trust that any particular incoming connection is not related to a DDOS. If a host connects to the public internet, that's not possible.

[fweespeech]

Well, if its a pure bastion, the only services to compromise is SSH and the package management [e.g. apt].

If either of those get compromised, you are hosed anyway.