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: [email protected]
Reporter: [email protected]
$ 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.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
