BUG: When using SSH TUNNEL option host fingerprints aren't saved

[lars18th]

trafficstars

Using last nightly build, when using the SSH TUNNEL option (Jump Host proxy) the target host fingerprint is not stored even you select to do it.

Expected Behavior

When selecting YES to store the fingerprint then the next time you connect to this server it's needed to be known.

Current Behavior

Every time you connect to the server you see that the fingerprint is not known.

Possible Solution

You need to fix the error checking if the correct fingerprint is stored.

Steps to Reproduce (for bugs)

1. Create a new SSH connection using the SSH TUNNEL option.
2. Connect to the server and pass the login of the jump server.
3. When connecting to the target server, in the window asking about the fingerprint select YES.
4. Close the connection and restart it... you will return to see the fingerprint window.

Context

This bug appears in the last nightly build that includes the SSH TUNNEL functionality.

Your Environment

• Version used: 1.77.2.41427
• Operating System and version (e.g. Windows 10 1709 x64): Windows 10 21H1 Home 64bit

[lars18th]

Hi @Kvarkas ,

I know you're very busy. However, this bug it's very simple to check it. So please, try it and update the label.

Thank you for your effort with this tool! 😉

[lars18th]

Hi,

I want to comment that with the last 20220107 Nightly build the problem persits.

I hope you want to test it to see that the problem is reproducible. Regards.

[Kvarkas]

its not problem to confirm, but currently its need to test in which parts its fails

[24mu13]

As workaround, you can manually configure PuTTY as described in the documentation.

I also tried to duplicate the key in the following registry path, using the right hostname but does not seem a valid workaround HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys

[lars18th]

Hi @24mu13 ,

As workaround, you can manually configure PuTTY as described in the documentation.

This guide will not work because the mRemoteNG is not using PuTTY but PuTTYNG: https://github.com/mRemoteNG/PuTTYNG. That's a fork of the original tool created to be used inside the mRemoteNG. So, only the developers could fix this trouble.

[24mu13]

This guide will not work because the mRemoteNG is not using PuTTY but PuTTYNG: https://github.com/mRemoteNG/PuTTYNG. That's a fork of the original tool created to be used inside the mRemoteNG. So, only the developers could fix this trouble.

For me it worked well: if you read carefully the documentation the idea is to save the session using PuTTYNG and adding the host key manually. After that, of course selecting the session in mRemoteNG connection, does not complain anymore about fingerprint.

[simonai1254]

If you open Tools>Options>Advanced and "Launch Putty" it's sure that you have the correct environment to save your putty sessions so mRemoteNG really can read them...

[lars18th]

Hi @simonai1254 ,

If you open Tools>Options>Advanced and "Launch Putty" it's sure that you have the correct environment to save your putty sessions so mRemoteNG really can read them...

Thank you for the tip! I don't know about how to launch the PuTTYNG tool manually from the Settings. However, this is not a solution:

• I've created a new temporal session with the target host, and configured it using a socks proxy opened inside the bastion server with another ssh connection (I don't know how to configure in PuTTYNG the SSH TUNNEL connection directly). And then I've added the fingerprint when connecting to the target host. After I can connect with PuTTYNG using the saved session and it doesn't ask (as expected) for the fingerprint. However, when connecting with mRemoteNG using the SSH TUNNEL the problem continues: every time I want to connect to the target host using the SSH TUNNEL the same window appears: PuTTY Secutiry Alert... server's hot key is not cached... Accept, Connect Once, Cancel. Therefore the key IS NEVER SAVED.

I hope this annoying bug will be fixed soon. Regards.

[lars18th]

Hi @Kvarkas ,

its not problem to confirm, but currently its need to test in which parts its fails

Please, don't think this is stupid. But could you please add the label "bug" to this issue? I feel it's a mistake. And even it's true that at time a lot of issues remain open. So therefore you have a lot of work pending, and I don't want to introduce noise. But for this reason I want to contribute almost helping with the organization. That's my 5cents.

Regards and thank you for continuing with this very good project! 👍