Passwordless SSH login into WSL2 failing

Question

I've followed Scott Hanselman's instructions found this blog post to setup an open-ssh server

in summary I've done the following:

# in WSL2 - install openssh-server
sudo apt install openssh-server

# in WSL2 - check ssh version
ssh -V # -> OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020

# in WSL2 - generate new host keys
ssh-keygen -t ras -b 4096 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

The private keys have permissions set to 600, and the public keys are 644

My sshd_config for your reference

#   $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

Port 2222
#AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
# @amin: Removed second one AuthorizedKeysFile  .ssh/authorized_keys .ssh/authorized_keys2
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

On WSL2 we don't have systemd so I start SSH with service ssh start

Now if I open up Powershell and ssh into my WSL2 using ssh -p 2222 myuser@wsl2ip I face no problems logging in with my password.

Next I copy over my windows public key from Win into WSL2 by running

type $env:USERPROFILE\.ssh\id_rsa.pub | ssh -p 2222 myUser@wsl2 "cat >> .ssh/authorized_keys"

and the contents there look like

ssh-rsa AAAAB3N************O1s= myWinUser@DESKTOP-AE*****

and the permissions in my WSL2 ~/.ssh look like

-rw------- 1   575 Jan 17 14:32 authorized_keys
-rw------- 1    97 Aug 30 11:17 config
-r-------- 1   411 Dec  2  2020 id_ed25519
-rw------- 1   100 Dec  2  2020 id_ed25519.pub
-rw------- 1  3389 Jan 17  2021 id_rsa
-rw-r--r-- 1   749 Jan 17  2021 id_rsa.pub
-rw-r--r-- 1  4866 Oct  7 16:19 known_hosts

, and turn off PasswordAuthentication by setting it to no in WSL2's sshd_config

Anytime I try to login with my ssh key I get

myuser@wsl2ip: Permission denied (publickey)

The same thing happens if I repeat the same process with RSA, RSA4096, or ED25519 keys.

What gives?

Answer 1

A few thoughts:

• First, the most likely reason for it failing is as Ramhound mentioned in the comments -- Key permissions. You just mentioned copying over the private key from Windows to ~/.ssh/authorized_keys, but you didn't mention changing the permissions. Try:

  chmod 600 ~/.ssh/authorized_keys
  

• Hopefully, that will work, but if it doesn't, try:

  sudo service ssh stop
  sudo mkdir /run/sshd
  sudo chmod 0755 /run/sshd
  sudo /usr/sbin/sshd -d
  

  That will run sshd in the foreground with additional debugging. Hopefully that will tell you why the key is being denied.

---

Preferred Method of Enabling SSH into WSL2

The page you linked to in your question is the one that says:

DO NOT DO THE INSTRUCTIONS IN THIS POST until you have read the FOLLOW UP THE EASY WAY how to SSH into Bash and WSL2 on Windows 10 from an external machine and made the right decision for YOU!

So I'd be curious why you selected the older, port-forwarding method over the alternative that he proposes for setting the Windows OpenSSH shell to the bash.exe (outdated info, but still works) command.

Regardless, I (and others) feel there's a much better alternative to either of Hanselman's techniques.

Advantages of this method:

• No port forwarding required
• Minimal firewall work needed since it relies on Windows services
• Works even if you have multiple WSL distributions installed
• Works with sshfs, scp, sftp, Ansible, and any app or service that requires a real SSH connection.

The summary is that:

• We rely on WSL2's ability to forward "localhost" connections on Windows to WSL (a.k.a. localhost forwarding).
• We use Windows OpenSSH server as a JumpHost to the WSL2 OpenSSH server.

The initial setup for this is the same as for Hanselman's "easy method". Start by enabling the Windows OpenSSH server on port 22.

• (Especially for future readers) I recommend simply following the Microsoft docs for the latest information, but I'm copying the relevant commands in here as well. From PowerShell:

  # Sounds like you had the Client already installed, at least
  Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 
  Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
  
  Start-Service sshd
  Set-Service -Name sshd -StartupType 'Automatic'
  
  # Confirm the Firewall rule is configured. It should be created automatically by setup. Run the following to verify
  if (!(Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinue | Select-Object Name, Enabled)) {
      Write-Output "Firewall Rule 'OpenSSH-Server-In-TCP' does not exist, creating it..."
      New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
  } else {
      Write-Output "Firewall rule 'OpenSSH-Server-In-TCP' has been created and exists."
  }
  

• Recommended if you are an Administrator on your Windows install -- Edit C:\Program Data\ssh\sshd_config and comment out the following lines:

  #Match Group administrators
  #       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
  

• While you are editing that, I assume you will want to set:

  PasswordAuthentication no
  

• By default, Windows OpenSSH looks for C:\Program Data\ssh\administrators_authorized_keys (see this question). By commenting these lines out, you will use your %userprofile%\.ssh\authorized_keys instead.

• Add your public key to %userprofile%\.ssh\authorized_keys. Make sure that permissions are restrictive per this answer (or related answers).

• Confirm that you can log to Windows OpenSSH from WSL using your key:

  ssh -i <path_to_private_key> "${HOSTNAME}.local"
  

At this point, you really have terminal access to WSL2 through Windows OpenSSH already.

From any machine on the network:

ssh -t <windows_host_or_ip> wsl

This will simply run the wsl command after the connection to Windows.

That works for shell access, but if you need "real" ssh access to WSL for Andible, sshfs, sftp, scp, etc., then read on ...

Next (for anyone else reading this) configure OpenSSH in WSL. You've done this part already. And port 2222 is a good option.

Copy over your public key to ~/.ssh/authorized_keys (already done for you) and make sure your permissions are correct (as mentioned above).

If you haven't already, add your private key to ssh-agent via:

eval $(ssh-agent) # under Linux
ssh-add <path_to_key

(Note: Windows also supports ssh-add. Just make sure the "OpenSSH Authentication Service" is running).

At this point, you can use the Windows host as your JumpHost like so:

ssh -J <windows_host_or_ip> -p 2222 localhost

This connects to the Windows OpenSSH server (on port 22) which then turns around and connects to localhost:2222, which is your WSL2 instance.

As mentioned, this will now work for scp, sshfs, etc.

---

Optionally:

This technique has one "side-effect", in that localhost is stored as the same "known host" regardless of which port or jump host you use to connect. So if you do connect to multiple WSL instances in this way, ssh will start complaining about potential man-in-the-middle issues.

The best way to avoid this (and simplify things in general) is to create a Host entry in ~/.ssh/config. Let's say your Windows host name is bubblegum and your WSL distro is ubuntu. Add the following to ~/.ssh/config:

Host bubblegum_ubuntu  # Can be whatever you want
Hostname localhost
User <username> # If needed
Port 2222
ProxyJump bubblegum
UserKnownHostsFile ~/.ssh/known_hosts_bubblegum_ubuntu

That will redirect the known_host entry to a file that is only used for that particular host.

It also means that you can now:

ssh bubblegum_ubuntu
scp bubblegum_ubuntu:/home/username/filename .
sftp bubblegum_ubuntu
sshfs bubblegum_ubuntu:/ /mountpoint