[Bug 3112] ssh -o ControlPath=... -N immediately exits with server authorized_keys command, fine w/o ControlPath

[bugzilla-daemon at bugzilla.mindrot.org]

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.