openssh bugs - Jan 2020 - [Bug 3112] New: ssh -o ControlPath=... -N immediately exits with server authorized_keys command, fine w/o ControlPath

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

            Bug ID: 3112
           Summary: ssh -o ControlPath=... -N immediately exits with
                    server authorized_keys command, fine w/o ControlPath
           Product: Portable OpenSSH
           Version: 8.0p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cJ-mr at zougloub.eu

Managed to reduce the problem to the following:

1. Prepare ~/.ssh/authorized_keys file *running a command*:

   ssh-keygen -t ed25519 -f id_test

   echo 'command="true",restrict '"$(cat
id_test.pub)" >>
.ssh/authorized_keys

2. Run a first connection, multiplex master:

   ssh -i id_test -o ControlMaster=yes -o ControlPath=test -N localhost

3. Run a second connection, multiplex slave:

   ssh -i id_test -o ControlPath=test -N localhost

Observe that at step 3, the command immediately returns.
Expected result is to behave the same way as `ssh -i id_test -N
localhost`.

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

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

J?r?me Carretero <cJ-mr at zougloub.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ssh                         |sshd

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

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

--- Comment #1 from J?r?me Carretero <cJ-mr at zougloub.eu> ---
Also when command is in ~/.ssh/authorized_keys, another interesting
issue is (add port-forwarding to the authorized_keys line):

1. Run a first connection:

   ssh -i id_test -o ControlMaster=yes -o ControlPath=test -T -N
localhost

2. Run another connection:

   ssh -i id_test -o StreamLocalBindUnlink=yes -o ControlPath=test -o
"LocalForward=./test.sock /tmp/another.sock" -T -N localhost


Slave says:
mux_client_forward: forwarding request failed: Port forwarding failed
muxclient: master forward request failed

Master says:
unix_listener: cannot bind to path ./test.sock: Address already in use
mux_master_process_open_fwd: requested local forward ./test.sock:-2 ->
/tmp/another.sock:-2 failed

However with the slave running with -v we can see that the slave did
set the forwarding (looks like it re-connected directly to the server).
Kind of weird.

Then:


1. Run a first connection, adding -o StreamLocalBindUnlink=yes (why?):

   ssh -i id_test -o StreamLocalBindUnlink=yes -o ControlMaster=yes -o
ControlPath=test -T -N localhost

2. Run another connection:

   ssh -i id_test -o StreamLocalBindUnlink=yes -o ControlPath=test -o
"LocalForward=./test.sock /tmp/another.sock" -T -N localhost


The slave immediately exits now.
This doesn't happen if ControlPath is not added to 2.; it also doesn't
happen if "command" is not in the ~/.ssh/authorized_keys.

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
I think the problem here is that -N doesn't really make sense for
multiplexed passenger connections and there is hint or warning that
this is the case. What are you trying to achieve?

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Closing for lack of followup. It's possible that commit 2d34205dab
improved this.

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

J?r?me Carretero <cJ-mr at zougloub.eu> changed:

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

--- Comment #4 from J?r?me Carretero <cJ-mr at zougloub.eu> ---
I'm sorry Damien I hadn't seen your reply.

I tested again with OpenSSH_9.4p1, OpenSSL 3.1.2 1 Aug 2023 which I
believe is after the aforementioned commit, and the issue still exists.
> I think the problem here is that -N doesn't really make sense for
multiplexed passenger connections and there is hint or warning that this is the
case. What are you trying to achieve?
I hadn't seen that hint or warning, and I stumbled upon the issue while
trying to transparently use ControlMaster/ControlPath options during
regular SSH usage (setting up a master on first use, and then reusing
it, so as to reduce the connection latency).

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