sftp connection fails

[falcovic]

Version 8.9.1.0

OS: Windows 7

ssh connects correctly but, sftp fails to connect.
I tried with WinSCP, Filezilla, and OpenSSH client: same problem.
I tried also running client from local host: same problem
I tried also installing using scripts instead of msi file: same problem

The same configuration on 8.6.0 works correctly.
sshd_config.txt

[bagajjal]

Please make sure the win32-openssh folder containing sftp-server.exe is in the SYSTEM PATH environment variable.
To debug further, take a look at the sshd.log, sftp-server.log file. To enable the file based logging, please look at the wiki

[jantari]

I just want to add that we've been running into this problem as well.

Server OS: Windows Server 2022 Core, sshd installed via the MSI

testing SFTP from a client with a command like sftp -vvv user@windowsserver

we just got fairly cryptic output on the client side:

[...] # TRUNCATED

debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0

# Up until this point everything is normal and identical to connecting to an Win32-OpenSSH 8.6 server - which works
# But what comes after this starts to differ from the connection to a working Win32-OpenSSH 8.6:

debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o3 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)

debug3: send packet: type 1
debug1: fd 0 clearing O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 2796, received 2844 bytes, in 0.2 seconds
Bytes per second: sent 18108.9, received 18419.8
debug1: Exit status 1
Connection closed
Connection closed.

There is not much about this on the internet.

Things I checked:

✅ Win-OpenSSH Server (sshd) 8.6.0.0p1-Beta SSH and SFTP just works ootb
❌ Win-OpenSSH Server (sshd) 8.9.0.0p1-Beta SSH works but SFTP does not work
❌ Win-OpenSSH Server (sshd) 8.9.1.0p1-Beta SSH works but SFTP is broken just the same
✅ Win-OpenSSH Server (sshd) 8.9.0.0p1-Beta and 8.9.1.0p1-Beta SFTP both start working again after C:\Program Files\OpenSSH is added to the Machine-Scope PATH, but the fact that this is (now) required is not obvious from any client or server-side logs (I checked DEBUG3 sshd.log) nor is it in the release notes
❌The fact that I set up Win32-OpenSSH-Server with the MSI installer and this required addition to the machine PATH was not made automatically by the installer is a bug IMO

[pamapa]

jantari You saved my day, thanks for sharing!

[notamorningperson]

jantari thanks for sharing the information.
I'm looking at an old 2016 machine running OpenSSH 8.1p1 where sftp is working right out of the box and I cannot find any added settings in Machine-Scope PATH/ SYSTEM PATH environment variable.
Do you guys have any thoughts on that?

[jantari]

notamorningperson my thought is that 8.1 is super old and therefore of course not affected by this bug that we've established only affects the latest 8.9 - or what do you mean?

[notamorningperson]

I guess what I'm trying to say is, why NOW we need to add OpenSSH in the environment variables when this wasn't needed before. And it's not that the previous versions did it automatically during the install.

Just trying to figure out what to write in my documentation on why we are NOW modifying the environment variables on our servers when we didn't had to do it before.

[robertstrom]

I just ran into this on a new build of Windows 11. Built from Win11 installed from Media Creation Tool and then finished deployment via Auto Pilot install. Computer is AAD joined (not hybrid). I used the PowerShell command to enable SSH. I created a local user and I am connecting using that local user account. I was able to get connected via SSH without issue (using both user name and password and SSH keys) but SFTP would not work. Adding the path to the OpenSSH directory to the SYSTEM environmental variables did fix the issue but this was not easy to find and should be part of enabling the feature. As previously pointed out, it has worked without issue in the past. I have enabled the SSH feature several times and have not run into this issue with other systems. So, as mentioned above, WHY NOW? Why do we need to go through this undocumented step now?

[DS-Liu]

Please make sure the win32-openssh folder containing sftp-server.exe is in the SYSTEM PATH environment variable. To debug further, take a look at the sshd.log, sftp-server.log file. To enable the file based logging, please look at the wiki

Adding the folder containing sftp-server.exe to the SYSTEM PATH environment variable works for Windows server 2016 with Openssh version V8.9.1.0p1-Beta