SSH cannot connect to any non-local SSH servers on WSL 2

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.

Reference

1. Reset your WSL network connection trying to fix WSL2 media disconnected error
2. WSL2 SSH can't connect to any public SSH server
3. SSH connections hanging from WSL2

X Servers for Windows

When we run multiple thin Linux/Unix systems on virtual machines on a Windows host, we wish to have X server for windows. There are in fact a few free ones, at least for personal use. Here are some of these X servers.

• MobaXterm that integrates PuTTY and Cygwin/X with feature-rich GUI
   
• VcXsrv that is based on from xorg's source code, compiled with Visual Studio (Visual C++, so vc - X - srv)
   
• Cygwin/X.
   
• Xming. An older version of Xming is available for free, but new versions require a donation like $20. 
  

"git status" shows modifications, but "git diff" shows nothing

I encountered a strange problem about a git repository today, that is, when I do a git status, git reports there are modifications. However, when I do a git diff, git reports no difference, like the following,

$ git status .
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

        modified:   .gitignore

$ git diff
$

After a little bit digging, apparently a few others encountered the same problem as a Stack Overflow discussion indicates.

The cause of my case are two,

1. Some files have different line endings from the version in the repository as a result that I was working on a Windows Subsystem for Linux and had the git's configuration property core.autocrlf set as input. I revealed the Windows line ending using vim, as in the following,
   

   
   $ vim -b .gitignore
   # Compiled class file^M
   *.class^M
   ^M
   # Log file^M
   *.log^M
   ^M
   # BlueJ files^M
   *.ctxt^M
   

   
   where the ^M characters are the Windows line endings, i.e., CR LF. I got rid of the line endings using sed, as in,
   

   
    sed -i -e s/^M// .gitignore
   

   
   Note that we enter the line ending by pressing CRTL-V CRTRL-M
   
2. The second issue is that some files have different permissions from those in the repository. Since I was using a Windows Subsystem for Linux on a Windows host, it is difficult for me to set the permissions identical to those in the repository. However, we can let git to ignore permission difference, i.e.,
   

   
   git config --local core.filemode false
   

   
   where I only did this for the repository. If we wish to do this for globally for all repositories, just issue the command without the --local option.

"grep" does not work on WSL?

Does "grep" not always work on the Windows Subsystem for Linux (WSL) on Windows 10? I has been investigating this problem that bothered me a great deal. Here is what I saw,

$ vi josh.txt

What I saw in vi is,

  Josh
  Anonymous
~       
~                                                                        ~  

OK, let's grep something ...

$ grep "Josh" josh.txt
$ echo $?
1

Should I have seen a match and exit-code 0 instead? I haven't gotten a clue until I ran strace,

$ strace grep "Josh" josh.txt
...
openat(AT_FDCWD, "josh.txt", O_RDONLY|O_NOCTTY) = 3
fstat(3, {st_mode=S_IFREG|0777, st_size=42, ...}) = 0
read(3, "\377\376 \0 \0J\0o\0s\0h\0 \0\r\0\n\0 \0 \0A\0n\0o\0n\0"..., 98304) = 42
read(3, "", 98304)                      = 0
close(3)                                = 0
...
$

Good, I saw 'J', 'o, ..., but what are these '\377', '\376', ... Instead of doing octal numbers to hexadecimal number conversion, I let strace do this for me, and

$ strace grep "Josh" josh.txt
...
openat(AT_FDCWD, "josh.txt", O_RDONLY|O_NOCTTY) = 3
fstat(3, {st_mode=S_IFREG|0777, st_size=42, ...}) = 0
read(3, "\xff\xfe\x20\x00\x20\x00\x4a\x00\x6f\x00\x73\x00\x68\x00\x20\x00\x0d\x00\x0a\x00\x20\x00\x20\x00\x41\x00\x6e\x00\x6f\x00\x6e\x00"..., 98304) = 42
read(3, "", 98304)                      = 0
close(3)                                = 0                            = 0
...
$

Huh? No characters? What are these "\xff\xfe\x20\x00..."? How about

$ cat josh.txt
    J o s h
     A n o n y m o u s
$

At this moment, I realized that the character encoding is neither ASCII nor UTF-8, and it must be something else, and the leading bytes are the "Byte Order Marks (BOM)". Windows API documentation has a page that has the following,

Byte order mark	Description
EF BB BF	UTF-8
FF FE	UTF-16, little endian
FE FF	UTF-16, big endian
FF FE 00 00	UTF-32, little endian
00 00 FE FF	UTF-32, big-endian

Note

A byte order mark is not a control character that selects the byte order of the text.

It turns out the text file is encoded in "UTF-16, little endian". Just for fun, I ran file,

$ file josh.txt
josh.txt: Little-endian UTF-16 Unicode text, with CRLF line terminators
$

That's it! I got this file from downloading it in Webex on the Windows host, and Webex must have encoded it in the Windows default encoding scheme, "UTF-16, little endian".

How do I grep this file? There might be many other methods. But I just use the iconv command  to convert the encoding from utf-16 to utf-8, and then redirect the output to grep, like,

$ iconv -f utf-16le -t utf-8 josh.txt | grep "Josh"
  Josh
$ echo $?
0
$

Problem solved!

LOG4J on Windows Complaining about Console Code Page

I was running the Windows JVM with LOG4J 2.8.1 with SLF4J 2.7.5 on the Windows Subsystem for Linux and encountered an error as follows,

2019-10-24 16:03:19,902 main ERROR Unable to inject fields into builder class 
for plugin type class org.apache.logging.log4j.core.appender.ConsoleAppender, 
element Console. java.nio.charset.UnsupportedCharsetException: cp0

In the Windows Subsystem for Linux terminal, the code page returned was 0, which was the source of the code page cp0.

user@WSL:/mnt/c/Windows/System32$ chcp.com
Active code page: 0
user@WSL:/mnt/c/Windows/System32$

Interestingly, the returned code page is on Windows Command Prompt,

C:\Windows\System32>chcp
Active code page: 437

C:\Windows\System32>

To get rid of the problem, we need to inform Java the encoding scheme, e.g.,

java -Dsun.stdout.encoding=UTF-8 -Dsun.err.encoding=UTF-8 FooClass

where we assume we run the FooClass class.