openssh bugs - Sep 2025 - [Bug 3870] New: Provide ObscureKeystrokeTiming setting that only activates the feature during session set-up

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

            Bug ID: 3870
           Summary: Provide ObscureKeystrokeTiming setting that only
                    activates the feature during session set-up
           Product: Portable OpenSSH
           Version: 10.0p2
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: openssh at vanderhave.org

I like the idea behind ObscureKeystrokeTiming=yes especially against
attacks that are timing the network packets while the user's login
password is being typed and sent to the server possibly one character
at a time over the network. However, using ssh with X11 forwarding
combined with ObscureKeystrokeTiming=yes makes running graphical X11
programs in an interactive ssh session unbearably slow for me. 
Would it be possible to have an extra setting that is the same as
ObscureKeystrokeTiming=yes when the user is not logged in yet, and
changes to ObscureKeystrokeTiming=no when the user is logged in and
session set-up is completed, i.e. from the point onwards when forwarded
X11 information could start to be sent? 
I realize that this may still reveal information about keystrokes being
sent to the server-side shell's command line, editor, and similar, but
leaking some probability information about those keystrokes seems to be
less severe than leaking information about the login password that the
attacker might be able to guess and then verify if the ssh server is
world-reachable.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Are you sure you are using OpenSSH 10.0? We improved the automatic
deactivation of ObscureKeystrokeTiming before that release.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
This sounds like bug#3820 which was fixed *after* the 10.0 release.

Does applying
https://github.com/openssh/openssh-portable/commit/203bb88 and
https://github.com/openssh/openssh-portable/commit/dc6c134 fix the
problem for you?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
BTW:

(In reply to Frans van der Have from comment #0)
[...]
> Would it be possible to have an extra setting that is the same as
> ObscureKeystrokeTiming=yes when the user is not logged in yet, and
> changes to ObscureKeystrokeTiming=no when the user is logged in and
> session set-up is completed, [...] leaking information about
> the login password.
SSH password and keyboard-interactive authentications send their
passwords or other auth material in a single SSH packet, and thus are
not susceptible to inter-keystroke timing attacks even without
ObscureKeystrokeTiming.  ObscureKeystrokeTiming helps when passwords
are sent after a shell is started, for example for su or
non-passwordless sudo.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

--- Comment #4 from Frans van der Have <openssh at vanderhave.org> ---
If at least the login password is always sent in a single packet, then
my suggestion to change the ObscureKeystrokeTiming setting when the
session is established does not make sense and does not need any
further action. 

My findings are qualitatively similar to bug #3820. 

I downloaded three openssh versions, compiled them from source, and
tested using two ssh sessions like this having the same yes or no
setting for ObscureKeystrokeTiming:

1) ssh -L 2222:x11host:22 -o ObscureKeystrokeTiming=yes/no \
user at bastionhost.example.com 
2) ssh -CY -p 2222 -o ObscureKeystrokeTiming=yes/no
remoteusername at localhost

The connection from my location to bastionhost.example.com is over the
public internet with a ping time of about 10 ms. bastionhost and
x11host are on the same LAN. On x11host I run "time" on the scripted
startup+closing of a non-wayland X11 application that draws a lot of
small widgets in a large window, so it is quite hampered by the
'chattiness' of the X11 protocol. Running it locally is not instant
either, but a lot faster than either 40 or 80 seconds.

Timing results ('real' row from 'time') with a single run each:
version                setting   result 
ssh v  9.6p1 release   no        0m 40.153s
ssh v  9.6p1 release   yes       1m 23.263s
ssh v 10.0p2 release   no        0m 38.029s
ssh v 10.0p2 release   yes       1m 25.120s
ssh snap20250930       no        0m 42.645s
ssh snap20250930       yes       0m 38.794s

Conclusion: I think the changes after release 10.0 have fixed the
problem, either completely or to a great extent. 

I may put an ObscureKeystrokeTiming=no in my $HOME/.ssh/config on some
systems for the time being, but I expect remove it once version 10.2 or
later has trickled down to the Linux distribution releases I'm using.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3870

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
Thanks for confirming.  Closing this a duplicate of bug#3820.

*** This bug has been marked as a duplicate of bug 3820 ***

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.