On Windows, ParaView is finding bad Putty before good OpenSSH

wascott · September 23, 2024, 5:28pm

I just finished debugging a ParaView Windows to remote cluster connection. The issue was yet again that the user had an old version of putty on his machine which didn’t work. When a terminal window opens to accept a password into the cluster, the putty connection immediately fails and the terminal closes. Thus, there is no way to figure out what is going on. On Windows computers, ParaView looks for Putty first, then the system OpenSSH.

Why do we look for Putty first, and can we invert the order to look for OpenSSH first? Windows 11 and at least most versions of Windows 10 work correctly with OpenSSH. This should remove the issue i describe above.

Thanks.
@mwestphal @cory.quammen

mwestphal · September 24, 2024, 8:31am

Because Microsoft OpenSSH has an issue that putty does not have:

github.com/PowerShell/Win32-OpenSSH

Win32 OpenSSH Reverse Connection Tunnelling is not working

opened 12:28PM - 05 Oct 18 UTC

mwestphal

Issue-Discussion-Deprecated/use GitHub discussions

**Server OperatingSystem** any linux based os **Client OperatingSystem** Wi…ndows 10 with Spring Update **What is failing** There is definitely a bug in Microsoft OpenSSH implementation from 2018 Spring Update. How to test it : On the local (Windows 10), install Python3, Putty and make sure ssh is available. Then 1. Run a python http server in a terminal (on port 8000 by default) `python -m http.server` 2. Create a reverse connection ssh tunnel `ssh -R 8080:localhost:8000 user@remote` On the remote, connect trough the tunnel with telnet On The remote, connect to it trough telnet >telnet localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. The tunnel is still runnning but telnet disconnect almost instantly after the connection. If you replase `ssh` by the plink.exe from putty, it works flawlessly and you can connect with a browser. **Expected output** ``` >telnet localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. ``` **Actual output** ``` >telnet localhost 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. ```

There seems to be some kind of workaround, but it would require dedicated code in ParaView.

This should remove the issue i describe above.

Alternatively, you can just specify the ssh executable as documented here: 7. Remote and parallel visualization — ParaView Documentation 5.12.0 documentation

wascott · September 24, 2024, 5:55pm

Thanks Mathieu. I had remembered something like this. Two thoughts.

As this is creating issues with users that have older versions of Putty installed, or applications that include old versions of Putty installed, and is almost impossible to debug, is it possible to do a system call and figure out what version of Windows you are on? I know Windows 11 ssh works, shouldn’t we be using that?
Windows 10 is end of life’d October 14th, 2025. What do you think about planning to invert choosing system ssh and Putty next October? Again, selecting Putty first is causing hard to debug issues.

Thanks for the reminder that I can hard code the ssh. I will look into it for ParaView 5.13.1.

mwestphal · September 25, 2024, 4:48am

The issue I linked above is not fixed in Win11.

What is possible is to implement the workaround suggested in the issue (force ipv4) and then switch them.

woodscn · December 19, 2024, 7:57am

For what it’s worth, I’m of the opinion that PuTTY was a useful hack in its day, but one that should be left in the past along with implicit typing and goto statements.

In our case, the main problem is getting people to approve “another” SSH application, when the officially blessed one is some proprietary app with a GUI and a custom, non-standardized API.