Bug 3112 - ssh -o ControlPath=... -N immediately exits with server authorized_keys command, fine w/o ControlPath
Summary: ssh -o ControlPath=... -N immediately exits with server authorized_keys comma...
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.0p1
Hardware: Other Linux
: P5 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-14 15:14 AEDT by Jérôme Carretero
Modified: 2020-04-17 14:41 AEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme Carretero 2020-01-14 15:14:14 AEDT
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`.
Comment 1 Jérôme Carretero 2020-01-14 17:09:26 AEDT
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.
Comment 2 Damien Miller 2020-04-17 14:41:02 AEST
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?