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

OpenSSH server hangs while transfering files with SCP

Open hexindent opened this issue 3 years ago • 8 comments

Troubleshooting steps https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Terminal issue? please go through wiki https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH

Please answer the following

"OpenSSH for Windows" version ((Get-Item (Get-Command sshd).Source).VersionInfo.FileVersion) 8.1.0.1 ssh -V shows OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

Server OperatingSystem ((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion\" -Name ProductName).ProductName) Windows 10 Home but my system info is Windows 11 21H2 22000.376

Client OperatingSystem macOS Mojave, Terminal, OpenSSH_7.9p1, LibreSSL 2.7.3 I can SSH login the Windows OpenSSH server, but can't transfer files with SCP

What is failing transfering files with scp

Expected output file transfered

Actual output

scp -v ~/Downloads/test.txt r9kk:
Executing: program /usr/bin/ssh host r9kk, user (unspecified), command scp -v -t .
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/user/.ssh/config
debug1: /Users/user/.ssh/config line 14: Applying options for r9kk
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 192.168.50.39 [192.168.50.39] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/r9kk.pub type 3
debug1: identity file /Users/user/.ssh/r9kk.pub-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1
debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.50.39:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:iNcm2LsIVovNzGXjRHmPFTlyJxb+rSHBZdKR11n6piA
debug1: Host '192.168.50.39' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /Users/user/.ssh/r9kk.pub ED25519 SHA256:ySLDd9810vFyjCRc3HUxV/GyibwULAlubvsYD4ywuwg explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/user/.ssh/r9kk.pub ED25519 SHA256:ySLDd9810vFyjCRc3HUxV/GyibwULAlubvsYD4ywuwg explicit agent
debug1: Server accepts key: /Users/user/.ssh/r9kk.pub ED25519 SHA256:ySLDd9810vFyjCRc3HUxV/GyibwULAlubvsYD4ywuwg explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.50.39 ([192.168.50.39]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_CTYPE = UTF-8
debug1: Sending command: scp -v -t .
Sending file modes: C0644 5002 test.txt
^Cdebug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Killed by signal 2.

It hangs at Sending file modes: C0644 5002 test.txt and I have to press CTRL-C to abort.

hexindent avatar Dec 18 '21 09:12 hexindent

I don't know if this info helps, anyway, I'll post it here:

I installed WSL2 Ubuntu 20.04 and made my Windows OpenSSH default shell Windows\System32\bash.exe in the registry, so I can SSH to the Windows PC and use WSL.

hexindent avatar Dec 18 '21 09:12 hexindent

@hexindent Do you happen to have the server side logs?

NoMoreFood avatar Jan 03 '22 19:01 NoMoreFood

I also have this issue. I set server-side logging to Debug3 and got the following:

15520 2022-04-25 20:07:13.576 Starting session: command for mark from 192.168.1.152 port 57911 id 0
15520 2022-04-25 20:07:13.576 debug2: fd 9 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug2: fd 10 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug2: fd 11 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug2: fd 12 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug2: fd 13 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug2: fd 14 setting O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug3: shell: "c:\\windows\\system32\\bash.exe"
15520 2022-04-25 20:07:13.576 debug3: shell_option: -c
15520 2022-04-25 20:07:13.576 debug3: exec_command: scp.exe -v -t C:/Users/mark/Downloads
15520 2022-04-25 20:07:13.576 debug3: arg escape option: TRUE
15520 2022-04-25 20:07:13.576 debug3: spawn_argv[0]: "c:\\windows\\system32\\bash.exe"
15520 2022-04-25 20:07:13.576 debug3: spawning "c:\\windows\\system32\\bash.exe" -c "scp.exe -v -t C:/Users/mark/Downloads"
15520 2022-04-25 20:07:13.576 debug2: fd 4 setting TCP_NODELAY
15520 2022-04-25 20:07:13.576 debug3: fd 11 is O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug3: fd 10 is O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug3: fd 13 is O_NONBLOCK
15520 2022-04-25 20:07:13.576 debug3: send packet: type 99

I was trying to set up ssh/scp with wsl2 (ubuntu) as described in this blog: https://www.hanselman.com/blog/the-easy-way-how-to-ssh-into-bash-and-wsl2-on-windows-10-from-an-external-machine

markm77 avatar Apr 25 '22 19:04 markm77

For completeness, here's a typical client-side log:

PS C:\Users\mark\Downloads>  scp -v .\test.txt mark@desktop-xxxxxxx:"C:\Users\mark\Downloads"
Executing: program ssh.exe host desktop-xxxxxxx, user mark, command scp -v -t C:/Users/mark/Downloads
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

<snip>

debug1: Authentication succeeded (password).
Authenticated to desktop-xxxxxxx([192.168.1.81]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending command: scp -v -t C:/Users/mark/Downloads
Sending file modes: C0666 4 test.txt

markm77 avatar Apr 25 '22 19:04 markm77

One further point. It would be natural and desirable for scp to accept Linux-style paths when communicating with WSL2. However that does not work either. For example using scp -v .\test.txt mark@desktop-xxxxxxx:/mnt/c/Users/mark/Downloads hangs too.

Perhaps the root of this is that OpenSSH server support for connecting to bash/WSL is still a work in progress?

markm77 avatar Apr 25 '22 21:04 markm77

hi all. i am facing the same issue. thanks! :)

devacto avatar Jun 20 '22 15:06 devacto

I have the same issue. Also used https://www.hanselman.com/blog/the-easy-way-how-to-ssh-into-bash-and-wsl2-on-windows-10-from-an-external-machine to make windows' openssh server start bash. Trying to scp from a remote machine (windows or linux) files in either direction just hangs.

Maybe notable (obvious in hindsight) is that what happens is the ssh server (on windows) starts up bash with the native windows version of scp as argument. maybe this is the problem?

i.e. on the wsl server, the process is started with this cmdline:

/init /mnt/c/Windows/System32/OpenSSH/scp.exe scp.exe -f llvm.ztar

while the cwd is set to my wsl user's home (where the file does reside).

Is this supposed to work?! It's really terrible to not have scp working... :')

shuffle2 avatar Mar 22 '24 17:03 shuffle2

I note sshfs hangs in basically the same way (but with sftp-server.exe). I think this just means the idea of using windows' openssh server with bash shell is not advisable.

edit: putting following in C:\ProgramData\ssh\sshd_config:

Subsystem	sftp	/usr/lib/openssh/sftp-server

this seems to make sshfs mounting and file access work, at least

It feels a bit gross, but not sure what a better solution should be

shuffle2 avatar Mar 22 '24 17:03 shuffle2