Win32-OpenSSH
Win32-OpenSSH copied to clipboard
SSH, SFTP Not following user's home directory
Good afternoon,
- I'm new to using OpenSSH, so possibly this is user error, but it seems ssh/sftp are not following the home directory of the windows user. From what I've found, ChrootDirectory is not applicable in Win32, and the user home must be used. I created a local user of 'test2', set the home directory (in user config) to \test2home, and restarted SSHD.
If I connect to server through ssh or sftp (using user/pass), the default/home directory is c:\users\test2.
- within SSH echo %HOME% returns c:\Users\test2, and echo %HOMEPATH% returns \Users\test2
If I log into the server locally and opening a cmd prompt, the default directory/home directory is c:\test2home.
- within local windows cmd window echo %HOME% returns %HOME% and echo %HOMEPATH% returns \test2home.
- So it seems to me windows is correctly handling the home path which was set, but Win32-OpenSSH is not. Due to needing to lock a remote user access down to a single 'empty' folder for sftp only for file exchanges, I need to use a 'nonstandard' home folder.
- This is being used on Win Server 2008 R2.
- Any pointers if I'm doing something wrong, or correcting the issue would be great!
Thanks, ~Tim
Is there any progress or update on this? Having this same issue in Server 2012.
Same problem here, Windows Server 2012. A fix would be really appreciated.
Is there any way to get this more attention?
It's been a while. Is a fix for this forthcoming?
I tried to update the User's Home directory in User Properties under ADUC as the following,
-
Update to be using the Computer's C:\TestingFolder, But the folder is still server's C:\Users[username] after SFTP logged in.
-
Update to be using network share as Z: with \FTPServer\FTPHome%username%. After clicking Apply button, a new folder created as the value of the username. But the folder is still server's C:\Users[username] after SFTP logged in
I have the same problem. I also tried to use mklink to create a junction to link user's home directory (C:\Users[username]) to a different location (c:\sftproot[username] for example). For some reason it worked the first time when I connect, but subsequent tries landed me in C:\Windows\ for some reason...
Coming up on two years old, any progress? Does anyone have a work-around that works?
Home directory of the user is pulled from registry Location: SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\--USERSID-- Key: ProfileImagePath
Can you please add details on how exactly home directory is being configured for a local user?
manojampalam - The Key:ProfileImagePath does not appear to correspond to setting a local users home folder in user properties (Profile tab, Home folder section, Local Path). The method to set a home folder in windows is documented below, I am uncertain how that relates to ProfileImagePath.
MS Documentation: https://support.microsoft.com/en-us/help/816313/how-to-assign-a-home-folder-to-a-user
or as i scripted it: NET USER %myuser% %mypasswd% /ADD /comment:"created: %timestamp%" /homedir:F:\FTPRoot\LocalUser%myuser% /passwordchg:no /fullname:%myfullname%
OK Thanks. While I figure out how to programatically retrieve "HOMEPATH", I'm contemplating whether we should rely on it.
Currently, we store user's ssh configuration under user's profile, on the assumption that it would be deleted once the user account is gone (note that it will contain sensetive information like user's keys). Getting "homepath" on board will lead to confusion down the line, should ".ssh" be stored under user's profile directory or "homepath". What should "~" resolve to ? What about user's other libraries - pictures, videos... that are found under profile directory (by default).
Thoughts?
I would model it exactly how FTP(S) User Isolation is configured now (via IIS), admins familiar with FTP can apply the same mental logic to ssh configuration.
If the user ssh configuration (keys) are stored under the user profile's SID registry, that makes sense. I think tying it to a profile path (default or otherwise) may not be the best direction. SSH user arent signing into Windows desktop, which is when the profile dir's (pictures, videos, etc.) are created the first time a user signs into the desktop. SSH users are nothing more than remote FTP users looking to transfer files. I checked my current FTP(S) users, there is no profile directories created (they only FTP via winscp or filezilla).
I simpler (I think) method would be to add a couple of SSH params.
SSH_User_Isolation=Yes/No
SSH_User_Physical_Dir=F:\FTPRoot
so a user 'JOHN' would be restricted to F:\FTPRoot\JOHN\
Or dont reinvent something that has been solved in a similar manner with cygwin, use that as a model to define your user isolation too, i think its defined in etc\passwd file which is their user configuration file. This too would help with understanding by using similar configs.
Will take a look at how FTP in IIS works.
I want to point we would like to be as close as possible to how OpenSSH works on Unix. OpenSSH currently ends up creating the user's profile if user has logged on for the first time (via ssh). We ought to have a default user directory because that's what OpenSSH core code assumes and relies on. And we prefer this is something that automatically gets cleaned up when user account is deleted.
Makes sense, I dont have a Unix background. Keep after it, I think a good implementation of user isolation is a crucial piece of Win32-SSH. Thanks for your hard work.
Hi,
Shall I understand that the registry key mentioned "ProfileImagePath" is used only by OpenSSH and we can set it up to point to a different directory ?
Not sure if this is the right place to mention, but it is inherently risky to use the %userprofile% for anything since there are long running windows 10 bugs about it creating "temporary user profiles" and using it indefinitely or at weird inexplicable times. (I can't even find explanations on the internet about when and why it makes temporary user profiles)
This terrible workaround probably only works for a single user scenario:
AuthorizedKeysFile c:\Users\username\.ssh\authorized_keys
# too risky AuthorizedKeysFile .ssh\authorized_keys
In my case windows created a c:\Users\TEMP.hostname and started using it persistently