On Thu, 10 Aug 2023 at 20:44, Peter Stuge <peter@xxxxxxxx> wrote:
> Philipp Marek wrote:
> > An easy workaround is to use a password manager (a plain file as a minimum)
>
> If you can/want to use a file then consider using a key instead.
>
> publickey authentication is non-interactive on the wire and the key is
> already unlocked so packet timing leaks nothing about your passphrase.
Just to be clear: SSH's password authentication is not subject to this
attack. The client sends the whole password in a single
SSH_MSG_USERAUTH_REQUEST packet (see RFC4252 section 8) so there's no
inter-keystroke timing. Same goes for keyboard-interactive (RFC4256).
The issue is that if during an interactive session you invoke
something that wants a password which it reads from the tty (eg su,
sudo, ssh-add or a second ssh invocation) that the potential exists to
leak keystroke timing.
If you needed to do a two-hop ssh then using either of pubkey via
agent forwarding or jumphost would avoid the timing leaving the client
machine.
--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
