Windows terminal tab freezes when ssh is disconnected within WSL

[ismailhkose]

Windows Terminal version (or Windows build number)

10.0.19043.985, 1.7.1033.0

Other Software

Windows 10 21H1 (OS Build 19043.985)
Windows Terminal Version: 1.7.1033.0

Cygwin64
Cygwin mintty 3.4.2 (x86_64-pc-cygwin) [Windows 19043]
OpenSSH_8.4p1, OpenSSL 1.1.1f 31 Mar 2020

WSL
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
Linux -T480 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu Workstation
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
tmux 3.2

Steps to reproduce

1 - VPN is connected to corporate network.
2 - Open Windows Terminal and start Ubuntu 18.04 WSL2
3 - SSH to remote machine within WSL2. I ssh to my Ubuntu 18.04 workstation in corporate network.
4 - Create a new tmux session session. tmux new -s test
5 - Disconnect VPN (Uncheck connect automatically)

At this step, terminal freeze should be reproduced, and it should not be responding to any keys, which is a bug 1. I have to close the terminal tab, and open another one to continue.

Expected Behavior

1- When VPN is disconnected, and ssh should be disconnected within the terminal as Cygwin does. However, Windows terminal gets stuck though.

Actual Behavior

1 - Windows Terminal has a blinking cursor, however; it doesn't response to any key ctrl+c or any other keys.
2 - It doesn't seem to try disconnects after connection timeout. Terminal hangs. The only way is to close the terminal tab.

[DHowett]

Thanks for filing this! Terminal doesn't actually control what happens here -- its job is to get characters out of SSH on to the screen, and from your keyboard back into SSH... or whatever application is connected. How a process handles the socket dropping, or SIGINT (from Ctrl+C), or user input is up to that process, at the end of the day.

When you get it into this state, if you press the following:

ENTER ~ .

what happens?

[ismailhkose]

I get the following message.
Connection to <IP> closed.

[DHowett]

It looks like Terminal is still passing input to the SSH process, as the SSH "session break" key combo continues to work. 😄

At the end of the day... if an application inside Terminal isn't responding normally it's much more likely to be the application's fault rather than Terminal's. You'd probably observe the same behavior if you used wsl inside the console host.

There's a chance, of course, that it's a WSL issue. Given though that it's WSL2, that's also unlikely. Sometimes SSH just thinks it's still connected.

[ismailhkose]

I don't get this error when I use Cygwin as a terminal. Please see the openssh and terminal versions in the first message. Any idea?

[DHowett]

The Cygwin runtime handles the "link disappeared while we were using it" state better than what you're seeing in WSL. This is probably because the Cygwin runtime is using Windows sockets natively, whereas WSL is running in a hypervisor with some network forwarding and stuff so it's missing the connection drop event.

If you run WSL outside of Windows Terminal, it's going to behave the same way.

[ismailhkose]

So, where should I file this bug to?

[ismailhkose]

I created a networking related issue in WSL, but I am not sure how relevant it is.
microsoft/WSL#7030

[Petros626]

I did the following, which worked for me (Windows 10 & WSL2):

1. sudo nano /etc/ssh/ssh_config
2. Under section Host* add ServerAliveInterval 5 (I guess any value is okay?)
3. sudo nano /etc/ssh/sshd_config
4. Near the end of the file search for: ClientAliveInterval 60; TCPKeepAlive yes; ClientAliveCountMax 10000
5. service ssh restart
6. ssh [email protected]