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

Damien Miller wrote in
 <678cc9a1-1129-61d9-49e5-c8eac5c54547 at mindrot.org>:
 |On Tue, 14 Oct 2025, Steffen Nurpmeso wrote:
 |> 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.
 ...
 |of course. ^C, ^Z etc are processed *by the server*. If there is no
 |connectivity to the server then they can't be processed.
 |
 |~. is processed by the ssh client, so you should be able to use it
 |under most circumstances.
 |
 |Use [enter]~. to terminate a stuck ssh connection.

But this only works at the beginning of a line.
Only then the client turns this mechanism "hot".
This condition requires that the network gets stuck at exactly
that time, directly after i hit a newline, otherwise i sit
completely helpless at the client prompt.  I mean i have a low
ServerAliveInterval, which likely is the timer that then counts
here, and ServerAliveCountMax is 3.  And i can fill the queue of
unsent bytes "to Bagdad and way back".

And if i want to continue before the timeout exits the client,
i need another terminal window; now it happened for whatever
reason, i used TSTP to suspend the client only, and then

  $ ssh root at kent
  Last login: Thu Oct 16 01:41:39 2025 from 203.0.113.1
  #?0|kent:~# ^C
  #?130|kent:~# ^C
  #?130|kent:~# stty
  speed 38400 baud; line = 0;
  -brkint -imaxbel iutf8
  #?0|kent:~#
  [1]+  Stopped                    ssh root at kent
  #?148|kent:nail.git$ fg
  ssh root at kent


  #?0|kent:~# stty
  stty
  speed 38400 baud; line = 0;
  -brkint -imaxbel iutf8
  #?0|kent:~# ^CConnection to kent closed.

I see no reason why after resume this ^C now suddenly causes the
client to exit?  It surely is not the bash on the server which
changed its behaviour?
But that only was an accidental discovery.

In the end this is why i asked.  The network stuck, and my
terminal did, too.  You can also not backspace back "like grazy"
until you think you surely reached the start of the line, then hit
RETURN for newline, to hotten the trigger, since all that is
only line processing by the shell on the server side.

So what, i do not know; likely all your internet connections are
super stable, and if not, then simply let that single window hang,
where is the problem.  Then again there is now that obfuscation
timer and all the stuff, there is plenty of state surrounding that
user input and the queue and the timer, right, what do i know,
echo "poo, queue fills packets are stuck, if you type the escape
in the next five seconds i will interpret it" and doing so surely
isn't it, not even without the echo, is it?

--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)

On Thu, 16 Oct 2025, Steffen Nurpmeso wrote:
> But this only works at the beginning of a line.
> Only then the client turns this mechanism "hot".
> This condition requires that the network gets stuck at exactly
> that time, directly after i hit a newline, otherwise i sit
> completely helpless at the client prompt.
I don't follow. The escape sequence is processed entirely on the
client and shouldn't be affected by network interruptions.

If you can replicate a case where it's not working, then please
try to capture a debug trace so we can figure out what's going wrong.
> I mean i have a low
> ServerAliveInterval, which likely is the timer that then counts
> here, and ServerAliveCountMax is 3.  And i can fill the queue of
> unsent bytes "to Bagdad and way back".
> 
> And if i want to continue before the timeout exits the client,
> i need another terminal window; now it happened for whatever
> reason, i used TSTP to suspend the client only, and then
> 
>   $ ssh root at kent
>   Last login: Thu Oct 16 01:41:39 2025 from 203.0.113.1
>   #?0|kent:~# ^C
>   #?130|kent:~# ^C
>   #?130|kent:~# stty
>   speed 38400 baud; line = 0;
>   -brkint -imaxbel iutf8
>   #?0|kent:~#
>   [1]+  Stopped                    ssh root at kent
>   #?148|kent:nail.git$ fg
>   ssh root at kent
> 
> 
>   #?0|kent:~# stty
>   stty
>   speed 38400 baud; line = 0;
>   -brkint -imaxbel iutf8
>   #?0|kent:~# ^CConnection to kent closed.
> 
> I see no reason why after resume this ^C now suddenly causes the
> client to exit?  It surely is not the bash on the server which
> changed its behaviour?
> But that only was an accidental discovery.
I'm not following what you're trying to do here, sorry.
> In the end this is why i asked.  The network stuck, and my
> terminal did, too.  You can also not backspace back "like grazy"
> until you think you surely reached the start of the line, then hit
> RETURN for newline, to hotten the trigger, since all that is
> only line processing by the shell on the server side.
Similarly, I don't understand why backspacing comes into this.
The sequence is just [enter]~.
> Then again there is now that obfuscation
> timer and all the stuff, there is plenty of state surrounding that
> user input and the queue and the timer, right, what do i know,
> echo "poo, queue fills packets are stuck, if you type the escape
> in the next five seconds i will interpret it" and doing so surely
> isn't it, not even without the echo, is it?
Keystroke timing obfuscation is all client side too and turns itself
off after a few seconds of inactivity. There's very little chance it
could fill a queue unless it was already 99.999% full. It's on a
completely different path to escape handling and I can't see any
way the two could interact.
> So what, i do not know; likely all your internet connections are
> super stable, and if not, then simply let that single window hang,
> where is the problem.
No, I have connections that hang occasionally. I use the escape
sequence to terminate them and I haven't encountered cases where
it's failed for a while.

-d

Steffen Nurpmeso wrote in
 <20251016000338.fpc0phas at steffen%sdaoden.eu>:
 |Damien Miller wrote in
 | <678cc9a1-1129-61d9-49e5-c8eac5c54547 at mindrot.org>:
 ||On Tue, 14 Oct 2025, Steffen Nurpmeso wrote:
 ||> 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.
 | ...
 ||of course. ^C, ^Z etc are processed *by the server*. If there is no
 ||connectivity to the server then they can't be processed.
 ||
 ||~. is processed by the ssh client, so you should be able to use it
 ||under most circumstances.
 ||
 ||Use [enter]~. to terminate a stuck ssh connection.
 |
 |But this only works at the beginning of a line.
 |Only then the client turns this mechanism "hot".
 |This condition requires that the network gets stuck at exactly
 |that time, directly after i hit a newline, otherwise i sit
 |completely helpless at the client prompt.[.]
 ...
 |In the end this is why i asked.  The network stuck, and my
 |terminal did, too.  You can also not backspace back "like grazy"
 |until you think you surely reached the start of the line, then hit
 |RETURN for newline, to hotten the trigger, since all that is
 |only line processing by the shell on the server side.
 ...
 |[.]there is plenty of state surrounding that
 |user input and the queue and the timer, right, what do i know,
 |echo "poo, queue fills packets are stuck, if you type the escape
 |in the next five seconds i will interpret it" and doing so surely
 |isn't it, not even without the echo, is it?

Or, you know, if the input queue grows and cannot be sent out, and
i then start hitting ^C, aka (would) create SIGINT through the
keyboard, then echo "i hear you master, i do not place this SIGINT
in the queue, but if you now use an escape, i'll dig it as that".
And i would say "thank you" in turn.
Just an idea...

--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)

>  |Use [enter]~. to terminate a stuck ssh connection.
> 
> But this only works at the beginning of a line.
> Only then the client turns this mechanism "hot".

Your interpretation of the situation is quite incorrect.

The two-character sequence <enter>~ is seen by the client, and it
looks for the next character.  A good character to use is ?

I think you've chosen to not understand.

On 16/10/2025 01:03, Steffen Nurpmeso wrote:
>   |Use [enter]~. to terminate a stuck ssh connection.
>
> But this only works at the beginning of a line.
"At the beginning of a line" means "immediately after pressing
Enter".?
That's why the sequence is [Enter] [Tilde] [Dot].

On 16/10/2025 02:03, Steffen Nurpmeso wrote:
> But this only works at the beginning of a line.
> Only then the client turns this mechanism "hot".
> This condition requires that the network gets stuck at exactly
> that time, directly after i hit a newline, otherwise i sit
> completely helpless at the client prompt.
[has VPN to the company and a shell on a remote server, via private IP 
outside the LAN's subnet, open]
[types "Foo", sans <ENTER>, into the shell]
[turns off VPN]
[types "Bar" <ENTER> <Tilda> <Dot> into the shell]
[no trace of the server echoing any of that back, but the client 
immediately terminates and returns me to the local shell as I hit <Dot> 
- all as expected and oft-used]

... I'm afraid that you'll have to state the exact version of OpenSSH 
involved on both sides when you see a different behavior ...

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4336 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20251016/2ccc2d63/attachment-0001.p7s>

I think I understand your point of confusion. From my reading, it seems as
though you are under the impression that the escape sequence must be entered at
"the beginning of a line", meaning it would line up like so:

noah at svr:~$ foo b
----------- ^

You wrote, "You can also not backspace back until you think you surely
reached
the start of the line, then RETURN ..."

Your assumption here is not correct though. You do not need to navigate
yourself "to the beginning of the line". The escape simply has to
follow a
newline. That is to say, you can be in the middle of a line, and hitting Enter
to put a newline character into the buffer, followed by ~. will cause the client
to disconnect. This is processed client-side so the state of the network is
irrelevant.

I understand that in the state of a network interruption, the characters you
enter will not be echoed back at you, but this is not required. The SSH client
will process the input anyway.

For the purpose of giving you an example, I have induced a network interruption:

noah at svr:~$ foo bConnection to -----.ca closed.
noah at T490:~$ 


I disconnected by hitting Enter, and followed it with ~.

Because there is no network connection, you will not see anything echoed back,
but this doesn't matter. You can even continue typing "abc...xyz"
prior to
"[Enter]~." You will not see it echoed, but the client is still
processing it.


With respect to this "^C" business, put it out of your mind. You want
~.



On Thu, 16 Oct 2025 02:03:38 +0200
Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> But this only works at the beginning of a line.
> Only then the client turns this mechanism "hot".
> This condition requires that the network gets stuck at exactly
> that time, directly after i hit a newline,
> In the end this is why i asked.  The network stuck, and my
> terminal did, too.  You can also not backspace back "like grazy"
> until you think you surely reached the start of the line, then hit
> RETURN for newline, to hotten the trigger, since all that is
> only line processing by the shell on the server side.
-- 
Noah Zalev