As the title stated, regardless how I try, I couldn't get SSH publication key authentication to work for a Linux host. It turns out that the Linux host that runs the SSH server has SELinux enabled. To make public key authnentication work for SSH, we simply need to configure SELinux, i.e.,
sudo setsebool -P use_nfs_home_dirs 1
Recently, I encountered a strange problem. That is, I cannot connect to any non-local SSH servers from a WSL 2 terminal using the ssh client from WSL 2. However, I would not have any problem to connect to these SSH servers using ssh.exe from Windows and PuTTY or other SSH clients on Windows. Here is what I observe when I try to connect Github.com,
ssh -vvv -T ssh@github.com
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /home/hui/.ssh/config
debug1: /home/hui/.ssh/config line 17: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "github.com" port 22
debug2: ssh_connect_direct
debug1: Connecting to github.com [140.82.113.3] port 22.
The process hangs on "Connecting to ..." until times out. I attempted all of the methods discussed in this threads and the method of adding a Firewall rule for WSL, but to no avail in my case. The solution finally works for me is to restart the Windows Container Networking service.
Using PowerShell, we can restart the service on command line as follows,
PS C:\WINDOWS\system32> Restart-Service -Force -Name hns
The solution came to me because I wanted to restart the networking stack of WSL and to see if it would resolve this issue. The method to do it comes from this Github gist. To restart the networking stack of WSL, run the following commands,
# Restart the Host Network Service
Restart-Service -Force -Name hns
# Restart the Windows Subsystem for Linux Manager
Restart-Service LxssManager
# Restart the WSL Network adapter
Restart-NetAdapter -Name "vEthernet (WSL)"
In my case, restarting the Windows Container Networking service (hns) is sufficient for me to resolve the problem.
I wrote the notes about how to synchronize two SSH hosts via a middle SSH gateway and how to access a SSH host via a SSH gateway. The assumption there is to use ssh in OpenSSH. But what if we want to do the same with PuTTY? I actually locate the answer on Stack Overflow. This post is just a bookmark to the answer.
Simply put, it is to use PuTTY's proxy setup on the user interface when we create a session for a host, and the proxy command follows the following format,
plink.exe %user@%proxyhost -P %proxyport -nc %host:%port
or
plink.exe %user@%proxyhost -pw %pass -P %proxyport -nc %host:%port
Note the two comments.
plink.exe is part of the PuTTY suite. plink.exe example is to use the password authentication. Since the password is part of the command line, someone can reveal the password by showing the process command line arguments, such as, using the methods in the notes written here. So use it with caution.
I believe that this is a rather common situation -- I want to copy files from one SSH host to the other; however, the SSH host I want to copy files from or copy files to is behind a SSH gateway. To describe the situation clearly, let's consider three SSH hosts, H, M, and O. I can log on to H via SSH, from H log on M via SSH, but from H not log on to O via SSH. To get to O, I have to log on to M first, and so M is a SSH gateway. In fact, this is a typical setup for many computational cluster, to access the cluster, you SSH to a SSH gateway. How do we copy files between H and O? Of course, we can always copy files from O to M, and M to H, which is somewhat inconvenient. Can we do better? Yes, via SSH's ProxyCommand option. Below we present two two scenarios.
Below is how we get to O "directly" from H assuming the username on M is alice_on_m and that on O alice_on_o.
ssh -o 'ProxyCommand ssh alice_on_m@M -W %h:%p' alice_on_o@O
Note that although we issue this command on H, H does not have to be able to resolve O; however, M must know O.
If you prefer the public key authentication to the password authentication, do the following instead,
ssh -o \
'ProxyCommand ssh -i ~/.ssh/private_key_for_m alice_on_m@M -W %h:%p' \
-i ~/.ssh/pri
vate_key_for_o alice_on_o@O
where we assume that private_key_for_m and private_key_for_o are two private keys on host H, and their respective public keys are in ~alice_on_m/.ssh/authorized_keys at M and ~alice_on_o/.ssh/authorized_keys at O.
To me, the most convenient method is to set up ~/.ssh/config file on H, with which, we will save some typing on the command line. Below is an example for the ~/.ssh/config file where we add two entries, one for M, and the other for O.
Host M
HostName M
ServerAliveInterval 240
User alice_on_m
AddKeysToAgent yes
IdentityFile ~/.ssh/private_key_for_m
Host O
HostName O
ServerAliveInterval 240
User alice_on_o
AddKeysToAgent yes
ProxyCommand ssh alice_on_m@M -W %h:%p
IdentityFile ~/.ssh/private_key_for_o
Once we set up this, we can get on O from H (via M) by simply issing the following command on H,
ssh alice_on_o@O
rsync
Assuming we set up ~/.ssh/config correctly, to copy files from O to H via M using rsync, we simply issue a command like the following,
rsync -avzr alice_on_o@O:./foo/ ./foo/
which copies the directory recursively ~alice_on_o/foo at host O to ./foo at host H. Here we also rely on rsync's ability to use SSH
as the transport protocol transparently.
Is this neat?