Dennis Clarke
2025-Oct-14 00:38 UTC
On the impossibility to use escape sequences when the networks hangs
On 10/13/25 20:28, Tim Rice via openssh-unix-dev wrote:>>> 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: ...Yes ... I had forgotten that. n# n# ^? Supported escape sequences: ^. - terminate connection (and any multiplexed sessions) ^B - send a BREAK to the remote system ^R - request rekey ^V/v - decrease/increase verbosity (LogLevel) ^^Z - suspend ssh ^# - list forwarded connections ^& - background ssh (when waiting for connections to terminate) ^? - this message ^^ - send the escape character by typing it twice (Note that escapes are only recognized immediately after newline.) n# Seems to work fine at the beginning of a line. :/ -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Damien Miller
2025-Oct-14 03:58 UTC
On the impossibility to use escape sequences when the networks hangs
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. -d