[csirac2]

Something that bothers me is (seemingly) widespread use of passphraseless ssh keys or, using ssh-agent without a timeout setting (so your keys are always loaded). I have to wonder if part of this is because ssh-agent -t starts the timeout clock for automatically unloading keys from whenever the agent was launched, rather than resetting the clock at each signing operation (which would mimic the familiar sudo behaviour).

This makes using ssh-agent with a reasonable timeout incredibly painful.

So you're left with either reentering your passphrase every 5/10/15mins, or basically never. Using smartcards for humans and TPMs for servers is a step in the right direction, but it seems ssh-agent is still missing this basic functionality - or am I missing something?

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