2

I have a bit of a confusion using WSL 2 on my Windows 10 machine regarding user names.

When I installed Windows 10 using my Microsoft Account, it created the user phili.

When I am in a powershell, the user home defaults to: C:\Users\phili\ which is /mnt/c/Users/phili/.ssh in WSL bash.

When I go to bash on WSL and cd ~ I end up in /home/phil.

The username in WSL seems to be phil which is different from the Windows username phili. I am not sure but I might have picked phil when installing WSL.

The problem I have is, that when I try to SSH into my WSL from my Macbook with ssh phil@<windows-host-ip> it won't accept my password (I have tried to change the pw also, no success). I can only login with ssh phili@<windows-host-ip> and my Windows password.

If I install the public key on my windows machine from my Macbook using ssh-copy-id phili@<windows-host-ip> it places them in /home/phil/.ssh/authorized_keys and not in C:\Users\phili\.ssh\authorized_keys.

EDIT: The files in /mnt/c/Users/phili/ are owned by user phil

phil@PHIL-DESKTOP:/mnt/c/Users/phili/.ssh$ ls
total 0
-rwxrwxrwx 1 phil phil  28 Oct  3 14:39 authorized_keys

Of course I could copy the public key manually, but this is not the point.

How can I clear up this mess with those usernames?

  • change the username in WSL to phili?
  • change the username in Windows from phili to phil?

I would prefer to use the username phil if possible.

Thanks for any tips.

Phil
  • 153
  • 2
  • 8
  • The user folder of a Microsoft Account defaults to 4 characters – John Oct 04 '21 at 17:21
  • I believe it defaults to 5 characters. That's also what I found when I googled this. – Phil Oct 04 '21 at 17:34
  • I think you might be correct. I looked on a machine here and it is indeed 5 characters. So the 4 character name may be something to do with WSL. I will check my own machine when I have a chance. – John Oct 04 '21 at 17:37
  • Just for clarity on the ssh issue, is this WSL1 or WSL2? Sounds like WSL1, but want to confirm. `wsl -l -v` (from PowerShell or CMD) to confirm. Thanks! – NotTheDr01ds Oct 04 '21 at 17:40
  • I am on WSL 2 on Windows 11 and the user name is my Microsoft account user name. So WSL is evolving – John Oct 04 '21 at 17:41
  • It is WSL 2, I edited the original question. Thanks for the hint. – Phil Oct 04 '21 at 17:47

1 Answers1

1

Some notes on usernames and home directories

  • WSL has a username, and Windows has a user name. They do not have to be the same, of course. And that's not a problem at all (nor related to your problem).

  • A WSL/Linux user has a home directory. By default, this is /home/<username>, but that does not have to be the case. In your case, it is, of course. Your WSL username is phil and your WSL/Linux home directory is /home/phil.

  • A Windows user has a home/profile directory that is (by default) named after the Microsoft Account for that user. And no, I don't find that ideal either. When I create my user on Windows, I first create it as a local user (not with a Microsoft account) so that it will set my username and the directory name the same. Then I convert my login to use the Microsoft account.

    This will become more difficult in Windows 11. My understanding is that it will require Windows 11 Pro or higher, but I'm not sure. When installing Win 11 Pro in a VM, I did my initial install with no network so that it could not use the Microsoft account.

  • Changing the username in Windows is easy. Changing the profile directory, not as much. I haven't tried it in a while, but according to this page there are Registry settings that use the Profile folder, so you'll have to muck with the Windows Registry in order to accomplish that.

    The alternative, as covered in this answer is to create a new user in Windows using a local account. Then copy everything over.

  • But regardless, changing the username isn't the solution to your problem. The main "issue" here is that Windows and WSL/Linux have different home directories. And you should not make these the same.

    You absolutely can't make Windows use your WSL/Linux home directory, since WSL/Linux is on a "virtualized" drive that lives in your Windows profile directory (%userprofile%\AppData\Local\Packages\<DistroPackage>\LocalState).

    You absolutely shouldn't make your WSL distribution use your Windows home directory. The Linux home directory should be on a Linux filesystem. For WSL, this is ext4. Putting your home directory on an NTFS drive will result in permission issues (somewhat resolvable, but not recommended) and performance issues (not currently resolvable).

Windows/Linux permission boundaries

The files in /mnt/c/Users/phili/ are owned by user phil

Well, actually no. The Windows drive is mounted by WSL with phil being the owner of the drive. That's why running ls in Linux shows your Linux user as the owner.

In PowerShell, run:

(Get-Acl C:\users\phili\).Owner
(Get-Acl C:\users\phili\).Access

And you'll see that SYSTEM is actually the Windows owner, and Windows user phili has full control.

ssh into WSL

I can only login with ssh phili@ and my Windows password.

This means to me that you have Windows OpenSSH installed. That's a good thing, as that's part of my recommended solution for sshing into WSL2 anyway.

I'm a bit confused that ssh-copy-id would have placed the files in your WSL/Linux home, though. ssh-copy-id should connect to the same server that ssh does (Windows OpenSSH in this case). Your ls command does show the authorized_keys in C:\Users\phili\, so perhaps you just have the directory names reversed?

Or perhaps you used these instructions for changing your Windows OpenSSH shell to WSL? That would explain it as well, since ssh-copy-id would place the files in the WSL/Linux OpenSSH location, but it's really the Windows OpenSSH that is handling things. In this case, the answer really is to just move the files over from /home/phil/.ssh/authorzied_keys to C:\Users\phili\.ssh\authorized_keys. By changing the registry setting for OpenSSH, you would "confuse" any client attempting to ssh-copy-id.

For some other options to ssh into WSL2, though, see my answer here.

NotTheDr01ds
  • 17,574
  • 4
  • 44
  • 81
  • Thanks @NotTheDr01ds a lot for this comprehensive answer. I now understand better the way users work in that context. And yes, I used the instructions by hanselman.com. Would you not recomment changing the Windows OpenSSH shell to WSL? – Phil Oct 04 '21 at 23:05
  • Like you said I copied over the public keys (authorized_keys) to the windows user .ssh directory. I actually prepared a second question about trying to ssh into my windows machine from my macbook with: `ssh phili@192.168.0.11` or `ssh -i ~/.ssh/id_rsa 192.168.0.11` This works fine with password, as long as the shell has not been changed. After I changed the sshd_config to `AuthorizedKeysFile .\.ssh\authorized_keys` it also works with the key files. – Phil Oct 04 '21 at 23:31
  • When I changed the shell to bash it also works with either password or keyfile, sshd_config includes `AuthorizedKeysFile ~/.ssh/authorized_keys`. However, when I changed de default shell for OpenSSH to Powershell with `New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Program Files\PowerShell\7\pwsh.exe" -PropertyType String -Force` I cannot login neither with password nor with the keyfiles. Any idea why this might be? Or is it neither recommended to use the powershell as default for open SSH? – Phil Oct 04 '21 at 23:37
  • 1
    Ok, I read [this post](https://superuser.com/questions/1629123/adding-parameters-to-defaultshell-in-windows-openssh-server-e-g-powershell-exe/1629407#1629407) of yours ad figured, I used the wrong path to the powershell, so I replaced it wtih: ``` New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force ``` Now ssh works directly into powershell as well, though as you explained, not with parameters added when running ssh. I might use your solution with the wrapper script if I need it. – Phil Oct 05 '21 at 00:26
  • @Phil Excellent! Glad that helped as well! Regarding the Hanselman method, I don't have a problem with it. Personally, though, I run multiple WSL distributions -- I have 12 installed on my main desktop right now, not even including the Docker instances. So I needed a technique that worked for all of them. Setting the OpenSSH shell only allows access to one. So I can `ssh windowshost wsl -d Tumbleweed` and get access to my openSUSE Tumbleweed installation (or any other). – NotTheDr01ds Oct 05 '21 at 01:50
  • All of your posts are very insightful! Docker will be next thing I will tackle, I can already run docker commands in my local macbook terminal, but I still have to figure out, how I can integrate this in my local macbook VS Code as well with remote-containers. If you have any posts about this, I'd be glad to know about them. I must add, I am quite new to docker and haven't fully grasped all of it yet. For now I just want to run some docker applications inside a linux docker and develop shell (and maybe python) scripts for/on it. – Phil Oct 05 '21 at 06:22
  • For now I have just installed the docker-cli on my macbook, would it be rather recommended to use Docker Desktop for mac rather to run remote containers? I can also start a new thread about this, once I have specific issues I won't have solved yet :) – Phil Oct 05 '21 at 06:24
  • @Phil Glad to help! As long as you have the `ssh` problems solved, I think I'd just run things using Docker Desktop (or engine) on the Windows/WSL side of things, but that' may depend on how you use the Mac in your workflow. I've done a [few Docker answers](https://stackoverflow.com/search?q=user%3A11810933+%5Bdocker%5D) on Stack Overflow, but probably nothing nearly as in-depth as the others on ssh. – NotTheDr01ds Oct 05 '21 at 14:05
  • I created a [new question](https://superuser.com/questions/1680555/docker-remote-containers-remote-access-issue-mac-m1-windows-wsl-2) about connecting from my macbook to the docker engine on my windows machine. Have you tried anything like this? – Phil Oct 08 '21 at 11:32