[Bug 3870] Provide ObscureKeystrokeTiming setting that only activates the feature during session set-up

[bugzilla-daemon at mindrot.org]

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.