On the impossibility to use escape sequences when the networks hangs

[Theo de Raadt]

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.