Win32-OpenSSH
Win32-OpenSSH copied to clipboard
PowerShell
%u is expand to domain\User
"OpenSSH for Windows" version 8.1
Server OperatingSystem Windows Server 2016
I want to use chroot. While %h is not expand to the homedir configured in the AD i use something like D:\homes%u. But unfortunately %u is expand to domain\username. I would expect, %u will be expand to the username.
I think to expand %u the Windows-NT/Prä Windows 2000 Username ist used.
Example: I tried to use D:\homes\sub%u for chroot-directory. But this will redirect the user to D:\homes\sub<domainname><username>, and of course, this folder doesn't exist.
This is especially problematic for authorized_keys. I wanted to do:
authorized_keys 'c:\ssh\authorized_keys\%u'
translates to a thing that doesn't exist which is frustrating.
Does always occur, or only on a computer with two accounts that have same user name, but each in a different domain (e.g., one machine local and one in Active Directory)? In the latter case, the domain prefix is needed to disambiguate between these two users.
Always. Even if you're not in a domain you get COMPUTERNAME\user. My AD-ified machines only have a single domain.
I bypassed this by changing my file structure to
\sftproot\<domain>\<username>\ as in
d:\sftproo\consonto\john\
@jaymzh migth be, i was actually working on chroot when i discovered int the log that it was looking in /sftpDir/<domain>/<username> but i cant see why it would noe extract \%u the same way in keys... try enabling logs SyslogFacility LOCAL0 and see where its looking for the keys
I did. Given authorized_keys 'c:\ssh\authorized_keys\%u' it looks like it should work, the logs show C:\ssh\authorized_keys\DOMAIN\user but creating files in that directory don't actually work, it says they're not there.
Hi, i think the easiest way is to get the username when using %u. Is there any easy way to delete the domain name form there result of %u. And at all: Does it make any sense to expand %u to domainname/username an not to username?
I used:
AuthorizedKeysFile __PROGRAMDATA__/ssh/authorized_keys/%u .ssh/authorized_keys
I put the public keys in C:\ProgramData\ssh\authorized_keys\domain\username. Note that it's all lower case. I made sure these files and directories have the same permissions as required for C:\ProgramData\ssh\administrators_authorized_keys in the documentation.
It works.
So to be clear @mtkraai - the "domain\user" gets translated into a directory for the domain and then the users are files in that directory? That's what I would expect, but it did not work back in 8.6 or whatever. It was looking for a file called "domain\user" which isn't allowed.... so it sounds like you're saying that's fixed and it properly parses that as a directory?
[Side note I no longer work at the company I was at when I ran into this bug, so I have not tried newer versions, but if you're saying that behavior is sorted, then we can probably just figure out what version that changed in, note it here, and close the bug.]
@jaymzh Yes, domain is a directory, user is a file.
The SSH version we're using is the one we installed a few days ago from Server 2019 optional features. It reports itself as OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5.
I have no idea how significant permissions may be. SSH processes refuse to use credentials files with permissions that are too loose. I ensured that the parent directory (C:\ProgramData\ssh\authorized_keys) has full control for SYSTEM and for the Administrators group and no others, and that the domain directory and key file inherit that with nothing else.
Yeah the permissions were correct. You could see it trying to open a file called domain\user which didn't work. It sounds like this is fixed.