Win32-OpenSSH
Win32-OpenSSH copied to clipboard
PowerShell
openssh-win32 fails randomly when using local groups for "Match Group" settings
Note that in all log entries, the user used is a local user "testsftp", using password authentication. The user is a member of the group "sftpcommonjail", but not "administrator". With two "Match Group" entries in sshd_config:
Match Group sftpcommonjail ChrootDirectory F:\jail Match Group administrators AuthorizedKeysFile PROGRAMDATA/ssh/administrators_authorized_keys
"OpenSSH for Windows" version 7.7.2.2
Server OperatingSystem Windows Server 2019 Datacenter
Client OperatingSystem Windows Server 2019 Datacenter (same server as above)
What is failing When "Match Group" is used in the sshd_config, sftp connections will randomly either work, get connection reset by peer, or say invalid password.
Expected output When it occasionally works, I get the output below: 5516 2021-08-11 16:38:20.812 debug1: user testsftp matched group list sftpcommonjail at line 97 5516 2021-08-11 16:38:20.812 debug1: user t does not match group list administrators at line 109 5516 2021-08-11 16:38:20.812 debug1: userauth-request for user testsftp service ssh-connection method keyboard-interactive [preauth] 5516 2021-08-11 16:38:20.812 debug1: attempt 1 failures 0 [preauth] 5516 2021-08-11 16:38:20.812 debug1: keyboard-interactive devs [preauth] 5516 2021-08-11 16:38:20.812 debug1: auth2_challenge: user=testsftp devs= [preauth] 5516 2021-08-11 16:38:20.812 debug1: kbdint_alloc: devices '' [preauth] 5516 2021-08-11 16:38:21.375 debug1: userauth-request for user testsftp service ssh-connection method password [preauth] 5516 2021-08-11 16:38:21.375 debug1: attempt 2 failures 1 [preauth] 5516 2021-08-11 16:38:21.375 Accepted password for testsftp from ::1 port 53530 ssh2 5516 2021-08-11 16:38:21.375 debug1: monitor_child_preauth: testsftp has been authenticated by privileged process
Note that the username gets rewritten to "t" in the second line. Based on the behaviour, it looks like the process checks against the name it gets from the previous step before it somehow mangles that variable, prints it and then the next step uses it. This is consistant with examples below from where it's failing.
Actual output When it fails with. Connection reset by ::1 port 22 Connection closed The log seems ok. 3680 2021-08-11 16:38:17.761 debug1: user testsftp matched group list sftpcommonjail at line 97 3680 2021-08-11 16:38:17.761 debug1: user testsftp does not match group list administrators at line 109
But when it fails with permission denied, it looks really bad:
5876 2021-08-11 16:33:51.934 debug1: user C:\Users\testsftp matched group list sftpcommonjail at line 97 5876 2021-08-11 16:33:51.934 debug1: get_passwd: LookupAccountName() failed: 1332. 5876 2021-08-11 16:33:51.934 debug1: Can't match group at line 109 because user n does not exist
3160 2021-08-11 16:33:58.567 debug1: user n matched group list sftpcommonjail at line 97 3160 2021-08-11 16:33:58.567 debug1: get_passwd: LookupAccountName() failed: 1332. 3160 2021-08-11 16:33:58.567 debug1: Can't match group at line 109 because user n does not exist
2996 2021-08-11 16:37:35.244 debug1: user t matched group list sftpcommonjail at line 97 2996 2021-08-11 16:37:35.244 debug1: get_passwd: LookupAccountName() failed: 1332. 2996 2021-08-11 16:37:35.244 debug1: Can't match group at line 109 because user t does not exist
In a previous test, I also got this: 6736 2021-08-11 15:46:05.429 debug1: user test_sftp_pw matched 'User test_sftp_pw' at line 88 6736 2021-08-11 15:46:05.429 debug1: user test_sftp_pw matched group list sftp_common_jail at line 96 6736 2021-08-11 15:46:05.429 debug1: user \001\002 does not match group list administrators at line 108
I have no idea why it replaces the username with "t", "n", "C:\Users\USERNAME" or even "\001\002" when checking them against groups, but it's probably related to why it randomly fails, or rather, randomly occasionally works.
As a workaround, I'm able to remove all "Match Group" entries, replacing them with multiple "Match User" instead, but as you can imagine, that's not even close to practical to scale.
Would also like to add that having "Match User" entries below the single default "Match Group" entry, also fails. While moving them above, will work. Which is consistant with the hypothesis that "Match Group" will have a chance of corrupting the username for any future checks.
To sum it up, for it to work, the config may only have a single "Match Group", and it has to be at the bottom. Which if you can reproduce it, is a pretty clear cut critical bug.
That might be true, but I want the stable version included with the OS, which I assume is the one getting security updates via windows update. Or is my assumptions incorrect, and the "official stable" version is left buggy and insecure?
Excuse my ignorance here, but windows update on my 2019 datacenter edition (OS build 17763.2114) tells me I'm fully up to date, while the openssh version installed via windows (not downloaded directly from github) is still 7.7.2.2 What am I missing?
Latest windows 10 is updated. Windows server 2019 is not updated. Next windows server 2022 (I think, it's currently in preview) has V8.1
I have the same issue at mine Windows Server 2019 version.
is the only fix to update the windows os?
