openssh unix dev - Oct 2025 - On the impossibility to use escape sequences when the networks hangs

Theo de Raadt wrote in
 <6240.1760455482 at cvs.openbsd.org>:
 |Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |> Damien Miller wrote in
 |>  <89d93aab-0510-31a4-9542-45a718702591 at mindrot.org>:
 |>|On Mon, 13 Oct 2025, Dennis Clarke via openssh-unix-dev wrote:
 |>|
 |>|> Seems to work fine at the beginning of a line. :/
 |>|
 |>|This was improved relatively recently:
 |>|
 |>|commit fec014785de198b9a325d1b94e324bb958c5fe7b
 |>|Author: djm at openbsd.org <djm at openbsd.org>
 |>|Date:   Wed Apr 20 04:19:11 2022 +0000
 |>|
 |>|    upstream: Try to continue running local I/O for channels in state
 |>|    
 |>|    OPEN during SSH transport rekeying. The most visible benefit \
 |>|    is that it
 |>|    should make ~-escapes work in the client (e.g. to exit) if the \
 |>|    connection
 |>|    happened to have stalled during a rekey event. Based work by and \
 |>|    ok dtucker@
 |>|    
 |>|    OpenBSD-Commit-ID: a66e8f254e92edd4ce09c9f750883ec8f1ea5f45
 |>|
 |>|Before this change (in OpenSSH 9.1), an unresponsive connection might
 |>|get uninterruptibly stuck if it was in the process of rekeying but
 |>|AFAIK that should no longer be the case.
 |> 
 |> Should i open a bug for that ^Z, the ^C inconsistency, and i
 |> do not know, it is a WireGuard VPN within which SSH is used,
 |> and at times no packets get through whatsoever, then no input is
 |> accepted at all, and ^C is not processed, too.
 |
 |I think you are confused.  <newline>~[letter] parsing is in the client
 |character input side, and the server or the link to the server has nothing
 |to do with it.

But input is impossible.  It is stuck.  Not even ^C processing
happens.  And, as i wrote, the code looks for newline (that much
i grasped before posting), and that i cannot input.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
> Theo de Raadt wrote in
>  <6240.1760455482 at cvs.openbsd.org>:
>  |Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>  |> Damien Miller wrote in
>  |>  <89d93aab-0510-31a4-9542-45a718702591 at mindrot.org>:
>  |>|On Mon, 13 Oct 2025, Dennis Clarke via openssh-unix-dev wrote:
>  |>|
>  |>|> Seems to work fine at the beginning of a line. :/
>  |>|
>  |>|This was improved relatively recently:
>  |>|
>  |>|commit fec014785de198b9a325d1b94e324bb958c5fe7b
>  |>|Author: djm at openbsd.org <djm at openbsd.org>
>  |>|Date:   Wed Apr 20 04:19:11 2022 +0000
>  |>|
>  |>|    upstream: Try to continue running local I/O for channels in
state
>  |>|    
>  |>|    OPEN during SSH transport rekeying. The most visible benefit \
>  |>|    is that it
>  |>|    should make ~-escapes work in the client (e.g. to exit) if the \
>  |>|    connection
>  |>|    happened to have stalled during a rekey event. Based work by and
\
>  |>|    ok dtucker@
>  |>|    
>  |>|    OpenBSD-Commit-ID: a66e8f254e92edd4ce09c9f750883ec8f1ea5f45
>  |>|
>  |>|Before this change (in OpenSSH 9.1), an unresponsive connection
might
>  |>|get uninterruptibly stuck if it was in the process of rekeying but
>  |>|AFAIK that should no longer be the case.
>  |> 
>  |> Should i open a bug for that ^Z, the ^C inconsistency, and i
>  |> do not know, it is a WireGuard VPN within which SSH is used,
>  |> and at times no packets get through whatsoever, then no input is
>  |> accepted at all, and ^C is not processed, too.
>  |
>  |I think you are confused.  <newline>~[letter] parsing is in the
client
>  |character input side, and the server or the link to the server has
nothing
>  |to do with it.
> 
> But input is impossible.  It is stuck.  Not even ^C processing
> happens.  And, as i wrote, the code looks for newline (that much
> i grasped before posting), and that i cannot input.
Again, I think you are quite confused about how this is supposed to work.

Of course ^C processing won't kill the local client.  The local tty
running the ssh client is in some sort of raw mode, and the ^C is not
processed by the kernel or shell, but is a regular character sent to the
ssh client process and read as a character.  That ssh client handles
that ^C as a character to be sent the remote end.  So of course it won't
kill the local client.  That is why the <newline>~ escape mechanism
exists.  The ssh processing continues in a buffer manner, and will see it,
and can interact.

I've not encountered a situation where <newline>~? doesn't work. 
In that
help message, you will also see that <newline>~^C does not exist as an
option.

So what you are talking about isn't make any sense.

Steffen Nurpmeso wrote in
 <20251014153948.s43LKday at steffen%sdaoden.eu>:
 |Theo de Raadt wrote in
 | <6240.1760455482 at cvs.openbsd.org>:
 ...
 ||I think you are confused.  <newline>~[letter] parsing is in the client
 ||character input side, and the server or the link to the server has nothing
 ||to do with it.
 |
 |But input is impossible.  It is stuck.  Not even ^C processing
 |happens.  And, as i wrote, the code looks for newline (that much
 |i grasped before posting), and that i cannot input.

i mean ok that after ^C .. maybe some special shell does *not*
"restart line processing" if it gets that, so maybe ssh cannot
assume anything after that ^C; still, i cannot input even that.

Look, i can easily reproduce it, though -vvv does not help:

  #?00.00 1/121|sdaoden:steffen$ debug3: obfuscate_keystroke_timing: stopping:
chaff time expired (197 chaff packets sent)
  debug3: obfuscate_keystroke_timing: starting: interval ~20ms
  ^C
  #?1300.00 1/121|sdaoden:steffen$ debug3: obfuscate_keystroke_timing: stopping:
chaff time expired (76 chaff packets sent)
  debug3: obfuscate_keystroke_timing: starting: interval ~20ms

^ disable packet transmission.  And hit ^C several times in a row.

  debug3: obfuscate_keystroke_timing: stopping: chaff time expired (501 chaff
packets sent)

^ then reenable packet transmission after dunno maybe 10 seconds

  ^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffe^C zcz^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffen$ ^C
  #?1300.00 1/121|sdaoden:steffen$

^ all these were in the input queue, i did not type at all.

And, hey, i do not write a patch, i just got paraded by Denys
Vlasenko who fixed a broken Dijkstra two-stack shell algorithm by
shrinking the code, whereas i added 2000 bytes and complicated
stack walks to fix it.  I get more detailed error conditions (eg
  sh: line 0: ?: condition, invalid precedence (1:v2:v3=3) (rest: I3:I2=12))
instead of
  sh: arithmetic syntax error
but i mean, that is not sufficient to heal my wounds.

Off for cycling.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)