Step1. Install OpenSSH Server on WSL​

Install OpenSSH Server on WSL2. Also, start the sshd service.

# WSL2 side
sudo apt install openssh-server
sudo service sshd start

Step2. Register the public key on the Windows side​

If you have not registered the public key on Windows, run the following command.

# Windows side
ssh-keygent -t ed25519

Next, register the public key on WSL2.

# Windows side
$pubkey = $(cat $HOME\.ssh\id_ed25519.pub)
wsl -- echo $pubkey `| tee -a `$HOME/.ssh/authorized_keys

Step3. Tunnel with SSH​

Connect to WSL2 from Windows via SSH.

# Windows side
ssh (wsl -- hostname -I).trim() -g -L8081:localhost:8080

Explanation of the command:

• (wsl -- hostname -I).trim() retrieves the IP address of WSL2.
• -g forwards the port to the LAN (accessible from external devices with an address like 192.168.x.x).
• -L is the local forward option. It forwards the server's port to a local port.
• 8081 and localhost:8080 mean that accessing http://localhost:8081 will forward to localhost:8080. Here, localhost refers to localhost as seen from the server side.

Step4. Start the server​

Start the server that you want to expose on WSL2.

# WSL2 side
ruby -run -e httpd . # Directory listing will be exposed

Step5. Access the server​

You can access the service at http://localhost:8081 or http://<IP address displayed by ipcconfig>:8081.

A disadvantage of tunnel connections is that it is tedious to tunnel every time. Although unstable, you can do the same thing by using netsh interface portproxy ~.

Public key authentication is a technique used in encryption and digital signatures that uses two keys, a public key and a private key, to authenticate communication partners and perform encryption. SSH stands for Secure Shell and is a protocol for securely exchanging commands and files over a network. SSH allows you to log in to a server using public key authentication.

Let's explain how it works specifically.

This article does not refer to mathematics.

About Public and Private Keys​

Public key authentication uses two keys: a public key and a private key. As the name suggests, the public key is a key that anyone can know, and you send it to your communication partner or make it publicly available on the internet. The private key is a key that only you possess and must never be revealed to anyone. It is mathematically very difficult to derive the private key from the public key. This property is utilized to realize encryption and digital signatures.

Digital Signatures​

Digital signatures are a technology to prove that the sender of data is the person themselves. Digital signatures are performed with the following steps:

Sender​

1. Hash the text.
2. Encrypt the hash with the private key (electronic signature).
3. Send the text and the electronic signature.

Receiver​

4. Receive the text and the electronic signature.
5. Decrypt the signature with the public key and retrieve the hash.
6. Hash the text and compare it with the hash obtained from the electronic signature (if the hashes are the same, the sender sent the text).

Digital signatures use the private key for signing and the public key for verification.

About SSH​

SSH stands for Secure Shell and is a protocol for securely exchanging commands and files over a network. SSH allows you to log in to a server using public key authentication. The advantages of SSH are as follows:

• Reduced risk of password leakage and brute-force attacks because you can log in without a password (although you can use a password).
• Data is encrypted, preventing eavesdropping and tampering with communication content.
• Enhances network security and access control using features such as port forwarding and tunneling.

In SSH, public key authentication is performed as follows:

1. The client generates a public key and a private key (ssh-keygen -t ed25519).
2. The client registers the client's public key (~/ .ssh/id_ed25519.pub) in advance on the server (~/ .ssh/authorized_keys).
3. When connecting to the server, the client digitally signs with its private key (~/ .ssh/id_ed25519).
4. The server verifies the digital signature with the client's public key (~/ .ssh/authorized_keys) and, if it is correct, allows login.

That's a summary of public key authentication and SSH. By using public key authentication and SSH, you can securely exchange commands and files over a network.

What is the slappaasswd command?​

The slappaasswd command is a command for generating passwords for OpenLDAP, which uses SSHA by default to hash the password.

Authentication mechanism​

In SSHA, the last 4 bytes of the generated hash are the salt. Authentication is performed by generating a hash from the input password and the stored salt, and checking if it matches the stored hash.

The following program, when given a valid password (e.g., admin), will produce the same original hash and generated hash.

require 'base64'
require 'digest'

pass = 'admin'
ssha = '{SSHA}23AUBfRZytVFNpe7onuFhyCSJOHRzCWh'
ssha =~ /{.+}(.+)/
salt256s = Base64.decode64(Regexp.last_match(1)).unpack('C*'[-4..-1])

salt = salt256s.pack('C*')
b_ssha = Digest::SHA1.digest(pass + salt)
Base64.strict_encode64(
 (b_ssha.unpack('C*') + salt256s).pack('C*')
)

[EOL]

• Password login is possible (although disabled in the settings)
• Permission denied occurs when using public key authentication

When connecting to localhost:22, the following error occurs:

hikari@localhost: Permission denied (publickey,keyboard-interactive).

Cause

It appears that the Administrators group, i.e., "administrator users", is referencing the public key in C:\ProgramData\ssh\administrators_authorized_keys for authentication by default.

Change this to $env:userprofile\.ssh\authorized_keys.

Solution

Open C:\ProgramData\ssh\sshd_config with administrator privileges and comment out the following two lines:

- Match Group administrators
-       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
+ #Match Group administrators
+ #      AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

After saving, restart the service.

Restart-Service sshd

pkg install openssh

If an error occurs​

If you run this on the Android version of termux, an error will occur. We recommend deleting the existing termux and installing termux from Github.

Start the server

sshd

Configure the public key

Add the client's public key (~/ .ssh/id_*.pub) to ~/ .ssh/authorized_keys in termux.

It's easy to copy and paste the public key by sending it to yourself via email or DM on Twitter.

# Example:
echo ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKYztjZfIVMl5o0J2DrigTsl1XgbSKMUgYCpfOfhMtmw hikari@B450M-K >> ~/.ssh/authorized_keys

Login

# Check the IP address of your smartphone
ip a

ssh 192.168.x.x -p 8022

Open an elevated terminal​

You need administrator privileges to edit the configuration file, so open a terminal with administrator privileges.

Right-click on the terminal icon and select "Run as administrator".

Open the configuration file in the terminal​

Run the following command:

notepad C:\ProgramData\ssh\sshd_config

Edit the configuration file​

- # PasswordAuthentication yes
+ PasswordAuthentication no

Change it to

and save the changes.

Restart the SSH server​

Return to the terminal and run the following command to restart the SSH server:

Restart-Service sshd

Connection test​

Test if the configuration is enabled.

Run the following command and if you see:

ssh localhost
user@localhost: Permission denied (publickey,keyboaard-interactive).

Then it's OK.

Local Port Forwarding​

ssh -L [client_port]:[host_to_forward]:[host_to_forward_port]

Suppose there is a client A, an SSH server B, and a host C, and you want to forward C:8080 to port 80 on A.

ssh -L80:C:8080 B

With this forwarding, accessing http://localhost from A will display the same content as http://C:8080 on B.

In summary, even if C is not visible from A, you can access the home network via SSH if port 22 is open to the outside. If B is visible from A, you can forward C's port to A via B.

Using -g allows access to C:8080 from computers on A's network using A's hostname.

Remote Port Forwarding​

ssh -R [client_port]:[host_to_forward]:[host_to_forward_port]

Unlike local forwarding, it forwards ports visible from the client instead of ports visible from the destination.

Suppose there is a client B, an SSH server A, and a host C, and you want to forward C:8080 to port 80 on A.

ssh -R80:C:8080 A

With this forwarding, accessing http://localhost from A will display the same content as http://C:8080 on B.

Even if B is not accessible from the outside, if a connection between B and A is established, you can forward the content of C to A. It is often used when you cannot directly operate B. When a connection between B and A is broken, tools like auto-ssh are often used to automatically reconnect.