# On Windows, ParaView is finding bad Putty before good OpenSSH
**URL:** https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428
**Category:** ParaView Support
**Created:** [September 23, 2024, 5:28pm UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428 "2024-09-23T17:28:36Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [September 23, 2024, 5:28pm UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428/1 "2024-09-23T17:28:36Z")
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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 24, 2024, 8:31am UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428/2 "2024-09-24T08:31:29Z")
> [@wascott](#):
>
> Why do we look for Putty first, and can we invert the order to look for OpenSSH first?
Because Microsoft OpenSSH has an issue that putty does not have:
>
>
> \*\*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](https://docs.paraview.org/en/latest/ReferenceManual/parallelDataVisualization.html#case-thirteen-ssh-run-server-command-with-complex-config)
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [September 24, 2024, 5:55pm UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428/3 "2024-09-24T17:55:31Z")
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.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [September 25, 2024, 4:48am UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428/4 "2024-09-25T04:48:29Z")
> [@wascott](#):
>
> 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?
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.
---
### Author:  [@woodscn](https://discourse.paraview.org/u/woodscn)
#### Post date: [December 19, 2024, 7:57am UTC](https://discourse.paraview.org/t/on-windows-paraview-is-finding-bad-putty-before-good-openssh/15428/5 "2024-12-19T07:57:36Z")
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.