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 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.
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.