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

On 10/13/25 18:03, Steffen Nurpmeso wrote:
> Hello.
> 
> In short: how does one control an interactive connection that
> currently is incapable to send/receive data?  ssh just hangs.
What happens if you try :

     $ ssh -e\^ -l someusername remotehost

I use that sort of thing all the time. The manpage says :

     -e escape_char
         Set the escape character for sessions with a pty (default:
'~').
         The escape character is only recognized at the beginning of a
         line.  The escape character followed by a dot (?.?) closes the
         connection; followed by control-Z suspends the connection; and
         followed by itself sends the escape character once. Setting the
         character to ?none? disables any escapes and makes the session
         fully transparent.

That escape character *should* be processed by the client side. Unless I
am confused about the question.


-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

> > In short: how does one control an interactive connection that
> > currently is incapable to send/receive data? ssh just hangs.
> 
> 
> What happens if you try :
> 
> $ ssh -e\^ -l someusername remotehost
> 
> I use that sort of thing all the time. The manpage says :
> 
> -e escape_char
> Set the escape character for sessions with a pty (default: '~').
> The escape character is only recognized at the beginning of a
> line. ... <snip>
I believe it's easy to overlook/forget the requirement: "The escape
character is only recognized at the beginning of a line."

I suppose using this sequence would solve the OP's issue: <Enter>~.
(aka <Enter><Shift-Backtick><Period>)

Indeed, this should be processed client-side. I've never had a problem
killing a hung connection once I remembered to always prefix the escape with a
newline.

~ Tim