openssh bugs - Jul 2022 - [Bug 3456] New: provide a way to have forwardings killed, when the remote command/shell finishes

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

            Bug ID: 3456
           Summary: provide a way to have forwardings killed, when the
                    remote command/shell finishes
           Product: Portable OpenSSH
           Version: v9.0p1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

When having a ssh connection, that sets up some forwardings (I tried
with LocalForward) and that executes a remote command (but I guess it's
the same when having not remote command but logging in
interactively)... the ssh connection is kept open as long as its
forwarding is still used by some connection, even when the remote
command/shell has finished.

AFAIU, that?s intentional behaviour and indeed it makes quite some
sense for many cases.

But I think there may be other use cases, when any forwardings shall be
killed once the remote command/shell has finished


I stumbled over this while doing the following:

I have a connection which sets up port forwardings for a VNC server and
the connection also executes a remote command which cleverly handles
starting that VNC server and also stopping it on Ctrl-C but e.g. not on
SIGHUP (i.e. accidental SSH connection loss).

That all works quite well, but in one case the SSH connection remains
open, even though the VNC server has already been stopped and the
remote command has finished.

This happens, when I actually connect to the VNC server with some
client, and quit the VNC server from within that X session.

It then stops the VNC server, my remote command also notices this after
a while, but netstat still shows me a connection from local to remote
which stays in CLOSE_WAIT forever.
Ctrl-C causes ssh to quit, also when I stop remmina (the VNC client I
use)

Guess there must be some issue with closing the connection when the
server is exited.



Anyway... from the SSH point of view it would be nice to be able to
forcefully kill any such forwarded connections, because it's already
clear that as soon as the remote command is finished, not connections
won't be possible anymore.


Cheers,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
I think you can do what you're describing on the command line,
something like:
$ ssh -L 1234:127.0.0.1:5900 yourserver 'vncserver; kill $PPID'

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.org>
---
I assume your idea here is that this kills the server side ssh process
and thereby also the forwarding, which isn't closed because of
whathever happens between remmina and vnc?

I tried it and while it works in principle it seems rather a hacky
workaround:
- the ssh client gives an error message as the connection is not
cleanly shut down
- exit status becomes 255 and not the one with which the remote command
exits

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
You could also do this using the multiplexing control socket and -O
cancel

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

--- Comment #4 from Christoph Anton Mitterer <calestyo at scientia.org>
---
> You could also do this using the multiplexing control socket and -O cancel
But AFAIU, this I'd need to do on the local side in an extra command.

So when I have some:
$ ssh foo.example.org

which sets up the forwarding and does via RemoteCommand start the
remote service... and that then "hangs" because the forwarding is kept
open even after the RemoteCommand has finished,... I would need to run
the cancel command from somewhere else, i.e. manually.

So that's merely "as good" as manually doing a Ctrl-C.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
AFAIK this would work:

ssh -oControlMaster=auto -oControlPersist=1s \
    -oControlPath=/path -L[forward] user at host command ; \
ssh -oControlPath=/path -Oexit user at host

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

--- Comment #6 from Christoph Anton Mitterer <calestyo at scientia.org>
---
Thanks Daimen... but still not particularly "user-friendly" in the
sense that one still has to write a special command (2x ssh with
special options) and cannot simply "ssh host" as usual.

Wouldn't it be possible to get a config option that simply decides what
should happen if there are still forwardings while the command has
finished, i.e. either keep them open or close them and thus exit?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|NEW                         |RESOLVED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
You can also remove forwardings from the ~C command-line, if you've
enabled that. IMO there are enough ways to do this already.

[djm at djm ~]$ ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~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.)

ssh> ?
Commands:
      -L[bind_address:]port:host:hostport    Request local forward
      -R[bind_address:]port:host:hostport    Request remote forward
      -D[bind_address:]port                  Request dynamic forward
      -KL[bind_address:]port                 Cancel local forward
      -KR[bind_address:]port                 Cancel remote forward
      -KD[bind_address:]port                 Cancel dynamic forward

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3456

--- Comment #8 from Christoph Anton Mitterer <calestyo at scientia.org>
---
Well, yes, but still requires extra action, and doesn't really work
when e.g. scripting... anyway...

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.