Win32-OpenSSH icon indicating copy to clipboard operation
Win32-OpenSSH copied to clipboard

ControlPath in ssh_config fails v0.0.3.0

Open dougransom opened this issue 8 years ago • 21 comments

ssh config

Host blue HostName underdoug.ca User underdou ControlPath c:/users/doug/.ssh/controlmasters_doug_blue ControlMaster auto ControlPersist 10m

c:\Program Files\OpenSSH>ssh blue muxclient socket(): Unknown error

dougransom avatar Nov 13 '16 16:11 dougransom

ControlMaster is not supported on Windows yet. See https://github.com/PowerShell/Win32-OpenSSH/wiki/Project-Scope

manojampalam avatar Nov 16 '16 19:11 manojampalam

Would be nice.

opoplawski avatar Jan 28 '20 22:01 opoplawski

It really would be nice. Please, bring it in! I am using SSH that comes with latest Widows 10:

OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

and it still is not there :-(

dobsa avatar Mar 27 '20 11:03 dobsa

Also noted in https://github.com/PowerShell/openssh-portable/issues/463

musm avatar Dec 04 '20 04:12 musm

Setting in ~/.ssh/config

ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

Leads to the errors when attempting to connect to any server:

getsockname failed: Bad file descriptor
channel_send_open: channel 0: unexpected internal error

musm avatar Dec 04 '20 04:12 musm

Still getting the error when trying the sockets for multiplexing.

C:\Users\mcgarrah>ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
C:\Users\mcgarrah>ssh -S ~/.ssh/control/test  [email protected]
getsockname failed: Not a socket
C:\Users\mcgarrah>ssh -vvv -S ~/.ssh/control/test  [email protected]
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
debug1: Reading configuration data C:\\Users\\u107250/.ssh/config
debug3: Failed to open file:C:\\ProgramData\\ssh/ssh_config error:2
debug3: w32_getpeername ERROR: not sock :3
debug3: w32_getpeername ERROR: not sock :3
debug1: getpeername failed: Not a socket
debug3: w32_getsockname ERROR: not sock :3
debug3: w32_getsockname ERROR: not sock :3
getsockname failed: Not a socket
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: ssh_packet_send_mux: type 90
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing
debug2: client_check_window_change: changed

mcgarrah avatar Apr 30 '21 01:04 mcgarrah

Adding this would be amazing. It's the last thing (for me) that windows openssh doesn't have that things like Putty/Kitty do.

mew1033 avatar Oct 19 '21 23:10 mew1033

Hi man, I think that problem is in permission of mutiplex folder. The service account can't create there the socket. If you add permission for multiplex folder problem solved (add SERVICE_ACCOUNT full control for 'control' folder in your case) I tested on newer version OpenSSH in windoze - but issue started with same symptoms. I hope the my note help you.

juvieorg avatar Dec 22 '21 19:12 juvieorg

It's a pity, a pity. Required functionality

solaris-ventus avatar Feb 09 '22 08:02 solaris-ventus

Here's another ping for ControlMaster functionality. Any updated word on when/if this might be coming? Thanks!

mew1033 avatar Oct 17 '22 06:10 mew1033

Unreliable information, please disregard

~~Hi everyone.~~

~~Here's a workaround dug from the depth of openssh bug list~~

~~Tested on windows 10 2h22 / GitBash~~ ~~* do your ssh -MNf with ControlMaster and ControlPath in the config unchanged~~ ~~* then for each mux connection run ssh -O proxy~~

~~Does not fix original issue, but gives you mux terminal.~~

FlorianDeconinck avatar Mar 23 '23 15:03 FlorianDeconinck

add SERVICE_ACCOUNT full control for 'control' folder in your case

If this indeed is a workaround solution, it would be helpful if you gave step by step instructions for doing the above.

woodda avatar May 13 '23 03:05 woodda

@FlorianDeconinck Not clear how it is supposed to work and what you were testing. -O option requires setting ControlPath (-S option). Setting ControlPath makes OpenSSH fail, as it is not supported on Windows (this is what this issue is about).

youk avatar Dec 11 '23 22:12 youk

@FlorianDeconinck Not clear how it is supposed to work and what you were testing. -O option requires setting ControlPath (-S option). Setting ControlPath makes OpenSSH fail, as it is not supported on Windows (this is what this issue is about).

Hey, I have actually moved on from this setup due too many problems stacking up, so indeed I might be talking out of nothing. I've edited the comment so it's disregarded.

Good luck on the bug hunt.

FlorianDeconinck avatar Dec 12 '23 16:12 FlorianDeconinck

@FlorianDeconinck Thanks. I don't think there is a bug. It's just not implemented. The only bug is that the corresponding command line options are available in the Windows port.

youk avatar Dec 12 '23 18:12 youk