2

I set up Windows 10's OpenSSH server to establish a ssh connection to WSL2's bash by a method described in this article: "THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine", and this document: "OpenSSH key management".

In summary, I run the following commands on PowerShell as admin:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\WINDOWS\System32\bash.exe" -PropertyType String -Force

After that, I could connect by ssh from PowerShell to WSL2's bash on localhost by ssh <my Windows username>@localhost using Windows' password.

Next, I want to connect not using a password, but using a key pair. So I created a key pair on PowerShell and located it as C:\Users\<my Windows username>\.ssh\authorized_keys.

cd C:\Users\<my Windows username>\.ssh
ssh-keygen -t ed25519 -f id_ed25519
copy id_ed25519.pub authorized_keys

But this could not allow me to connect localhost using the key pair. A command ssh -vvv -i C:\Users\<my Windows username>\.ssh\id_ed25519 <my Windows username>@localhost returns a permission error with a log line debug3: receive packet: type 51 just after offering public key of the private key.

As another try, I located the authorized_keys in WSL2's home directory /home/<my WSL2 username>/.ssh and run chmod 600, but the result of ssh on PowerShell is the same as above.

So my question is: How to connect the OpenSSH server on Windows 10 whose default shell is WSL2's bash, using a key pair? Where should I locate authorized_keys?

2
  • Enabling verbose mode should provide more insight in where your OpenSSH configuration is looking for keys at, where that location, is defined in your OpenSSH configuration file
    – Ramhound
    Commented May 24, 2021 at 1:40
  • Could you tell me how to enable the verbose mode? I tried to edit LogLevel to DEBUG in C:\ProgramData\ssh\sshd_config, but there are no such logs on Event Viewer.
    – nekketsuuu
    Commented May 24, 2021 at 2:41

1 Answer 1

5

I use a similar configuration, and there are a few things I've come across when troubleshooting this type of issue. You have two of them mentioned already in your question, so you are off to a good start. I'm just mentioning these here for others who come along looking at this answer:

  • Make sure you are using ECDSA keys rather than RSA. Windows OpenSSH server has a bug (fixed in the latest release, but not included in Windows) that causes RSA keys to fail. You are good here.

  • Troubleshoot permissions -- Make sure that the .ssh directory (location to be discussed later) is only accessible by SYSTEM, the user, and the Administrators group, at best. The same for any private key files in it.

Match Group administrators

Here's the most likely cause ... If your Windows' user is an administrator, then the default Windows OpenSSH configuration is probably "getting in the way" of our sensible Unix/Linux expectations ;-). Check your C:\ProgramData\ssh\sshd_config. By default, it probably has the following lines at the bottom:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

I'm assuming this is for the benefit of security on a multi-user system. Having one central location for maintaining the authorized keys list makes it easier to review and update that file. Having to search multiple user directories would require additional effort.

So you have two options:

  • Since you appear to be on a single-user Windows 10 system, you can just comment out those lines, restart the OpenSSH Server service, and you should then be able to use your authorized_keys in %userprofile%\.ssh\authorized_keys.

  • If you are someone who does maintain multi-user systems, you might want to just use the best-practice of putting the authorized keys in %programdata%\ssh\administrators_authorized_keys.

DefaultShell issues

Finally, I've seen the key being refused when there's an error in the DefaultShell registry key. You would likely have already spotted this in your ssh -vvv output. It would have returned something like:

User not allowed because shell C:\\WINDOWS\\System32\\bash.exe does not exist

So I'm guessing that's not your problem. That said, I would recommend using wsl.exe instead of bash.exe. The latter is not-quite-deprecated, but Microsoft calls it a "historical" command for launching WSL and now recommends the much more feature-rich (not to mention supported and tested), wsl.exe.

Note that you can also launch into a WSL session with additional options -- See my question/answer here for details, which is where I originally ran across the "does not exist" error that was causing a "type 51" refusal of the keys.

Other debugging steps

If none of the above works, you can also launch OpenSSH server in debug mode. See the full instructions here. psexec is somewhat optional if you need to run it as SYSTEM, but recommended if you hit a wall running it as the normal user.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .