openssh bugs - Oct 2024 - [Bug 3743] New: ControlMaster forces ForkAfterAuthentication even when not wanted, and can't be disabled

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

            Bug ID: 3743
           Summary: ControlMaster forces ForkAfterAuthentication even when
                    not wanted, and can't be disabled
           Product: Portable OpenSSH
           Version: 9.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: webmaster at shishnet.org

$ ssh -G hana | grep -i fork
forkafterauthentication no

$ ssh -N -o ControlMaster=no hana
(... ssh stays in the foreground for as long as the connection remains
open ...)

$ ssh -N -o ControlMaster=yes hana
$ (... ssh forked into the background, even with no -f, and
ForkAfterAuthentication=no ...)


FYI the use-case here comes from the Zed text editor, where they
initially create a connection with "-N" and "-o
ControlMaster=yes" just
to ensure the connection works and to keep it open, then do the real
work in other processes. However after starting ssh, they then check
whether or not the child process exists, and assume that the child
going missing means something went wrong. I'm not sure if that approach
is a good or bad idea, but either way, forking after authentication
when "ForkAfterAuthentication=no" feels like a bug.

[0]
https://github.com/zed-industries/zed/blob/ec5d6e96bb304886f49680b54e58c9b0e7221cd6/crates/remote/src/ssh_session.rs#L1137-L1150

"Start the master SSH process, which does not do anything except for
establish the connection and keep it open, allowing other ssh commands
to reuse it via a control socket."

[1]
https://github.com/zed-industries/zed/blob/ec5d6e96bb304886f49680b54e58c9b0e7221cd6/crates/remote/src/ssh_session.rs#L1183-L1191


I was able to reproduce this with the latest code from git, commit
fe6c6330c1a94c7a537efe9069853ce7a275c50a

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I can't reproduce this. I tried:

ssh -F none -F -oControlPath=/tmp/ctl -oControlMaster=yes host

and it didn't fork. Do you have ControlPersist enabled in your
configuration? That will fork implicitly, as described in the manual
page.

-- 
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=3743

--- Comment #2 from Shish <webmaster at shishnet.org> ---
Setting ControlPersist=no does indeed stop the automatic forking,
thanks for the hint :)

(It still feels weird to me that ControlPersist would control forking
after authentication and ForkAfterAuthentication is silently ignored,
but since there's a way to disable it that solves my immediate problem.
I'll leave it up to you to decide if this warrants a behaviour change /
a comment in the ForkAfterAuthentication section of the docs / just
close this ticket as noise)

-- 
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=3743

Shish <webmaster at shishnet.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ControlMaster forces        |ControlPersist forces
                   |ForkAfterAuthentication     |ForkAfterAuthentication
                   |even when not wanted, and   |even when not wanted
                   |can't be disabled           |

-- 
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=3743

--- Comment #3 from Shish <webmaster at shishnet.org> ---
Reading the docs and the source code for a few more hours, I am
actually more confused than I was to start with... but one bit of
clarity is that my confusion comes from detaching, not from forking
per-se.

Currently implemented behaviour seems to be:

                        | ControlPersist=no | ControlPersist=yes
------------------------+-------------------+-------------------------
ssh       host sleep 10 | attached          | attached
ssh -f    host sleep 10 | detached          | detached
ssh    -N host          | attached          | detached (??)
ssh -f -N host          | detached          | detached

Rows 1, 2 and 4 make sense to me. Row 3 feels weird, like the
detachment was a side-effect rather than intentional behaviour?

The code comments seem to imply that the persistent master forks off
into the background and expects a new mux-client to come along and run
in the foreground (by default) or background (with -f) -- but in the
case of -N, the new mux-client doesn't come along (or does it come
along and exit immediately? I'm a bit lost here), and we're left with
the master running in the background and the foreground becomes
detached by default rather than by choice.

-- 
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=3743

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
AFAIK the original issue here is closed. I'm neutral on the behaviour
of -N with ControlPersist; if you really feel this is erroneous then
please file a separate bug for that.

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