Re: Packet Timing and Data Leaks

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


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

Darren Tucker (dtucker at
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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux