Closed paulcalabro closed 1 year ago
This is a very important point IMO and should at least be documented as a practical risk, if not changed in the default configuration
If you assume a compromised client, this configuration leaves MFA neutered once the user logs in for the day, or however long you allow sessions to last. In practice, without restriction MaxSessions
, an attacker might not even notice that MFA is in place since the user experience is so seamless :)
It is an unpleasant reality that like most security controls comes down to a tradeoff between security and user experience. In my unsolicited opinion, doing "partial" MFA is a significant detriment to security and users should be strongly warned about this risk
If users need multiple sessions, perhaps they can be encouraged to utilize tmux
or screen
, or the MFA mechanism can be made more convenient- the YubiKey HID/button press mechanism is a great way to ease the pain of limiting MaxSessions
to 1.
BTW- I have no association with YubiKey aside from having implemented this exact solution once before with a very positive reception from users. Perhaps other vendors offer similar devices that don't require a user to unlock their phone and open an app to perform MFA
One additional note- a sophisticated attacker could also perform this attack even if the user did not explicitly enable ControlMaster
by doing runtime injection of an SSH protocol command channel. This is unlikely except in highly targeted organizations, but has been proven practically possible. Then again, assuming complete control of the client, an attacker could also simply edit the ~/.ssh/config
on the client and enable ControlMaster
in the config file themselves, hoping the user doesn't notice. Point being, client-side controls won't really help with this, in case there is any thought in that direction..
Just fyi, I'm traveling at the moment. I'll work on this when I get back.
Hi, we are clearing out stale issues. Would you like to submit a PR for documenting this as you suggested? Stale issues will be closed within the next few weeks, thank you!
It might be good to disable this line by default:
https://github.com/cloudposse/bastion/blob/8bb178fe2fefe8c3a5c9f5f63a00cf2ee91ec9d0/rootfs/etc/ssh/sshd_config#L28
By using this default value, a user can use SSH multiplexing on their side:
While this speeds things up, it has the side effect of using 2FA the first connection attempt and reusing that existing authenticated connection for all future connections. The keep-alive keeps the connection from getting severed.
If that machine on the untrusted network gets popped and the bad actor enumerates the control sockets or forces these settings upon the user, they could potentially bypass 2FA altogether.
Limiting
MaxSessions
would administratively make that not possible.Thoughts?