Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change of fingerprint causes client to be unable connect trough SSH #1719

Open
Heathland opened this issue Mar 11, 2020 · 7 comments
Open

Change of fingerprint causes client to be unable connect trough SSH #1719

Heathland opened this issue Mar 11, 2020 · 7 comments
Assignees
Labels
Projects

Comments

@Heathland
Copy link

Heathland commented Mar 11, 2020

Hi,

It seems that once a server that you used to connect to trough a SSH-tunnel changes it's fingerprint, you can't connect anymore. (This is on the windows client)
I've tried clearing the known_hosts in Users{{username}}.ssh but that doesn't work either.

The message that pops up in the error window is:

Failed to create SSH tunnel to server.name:22.

Error:
Error when starting up SSH session: -5

Is there any way of clearing the old fingerprint of this server ?

Robo3T 1.2.1
Windows 10

@simsekgokhan
Copy link
Collaborator

simsekgokhan commented Jun 22, 2020

Hi @Heathland , thanks a lot for reporting the problem. We plan to investigate this issue within the current Robo 1.4 development period.

@simsekgokhan simsekgokhan self-assigned this Jun 22, 2020
@simsekgokhan
Copy link
Collaborator

simsekgokhan commented Jun 24, 2020

Hi @Heathland , do you still have the problem?

1
We suggest you to double check your SSH config.
known_hosts sits on the client side to check if the server is trusted.
So you should be checking ~/.ssh/authorized_keys on server side.

More:
https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files
https://security.stackexchange.com/questions/20706/what-is-the-difference-between-authorized-keys-and-known-hosts-file-for-ssh

2
We could not reproduce your case. We used Windows machine as client, changed server's fingerprint but we were able to connect, did not have your problem.

3
Couple of suggestions:

  • Can you try with Robo 1.3?
  • You can try this <workaround solution> where you handle the SSH connection on terminal (command line on Windows or cygwin, putty etc..) instead of Robo.

@Heathland
Copy link
Author

Heathland commented Jun 24, 2020

Hi @simsekgokhan. Yes the issue still exists, also with 1.3.

I've checked the authorized_keys but since I can just connect to it using SSH with my key's, I wasn't expecting any issues, and indeed, the public key matches the one I'm using.

I would love to do some debugging if you want ?

As for the workaround, it's exactly what I've been using so far (using WSL).

@Heathland
Copy link
Author

Heathland commented Jun 24, 2020

Hi @simsekgokhan, speaking with my colleague shed some light on another possibility.
The SSH encryption of the server has changed as well. I was unaware of that.
We've gone from DSA to ED25519.

Could that be the issue ?

@simsekgokhan
Copy link
Collaborator

simsekgokhan commented Jun 25, 2020

@Heathland Thanks for that detail. Seems like the version of SSH library we are using libssh2 does not support ED25519.
However, they support it in their latest version. We will check how much of work upgrading libssh2 will be on our side.

And for your side, so your server is configured to accept only ED25519 keys? If RSA keys are supported, using RSA keys might be the quickest solution on your side.

pull bot pushed a commit to Pandinosaurus/robomongo that referenced this issue Jun 29, 2020
…ading libssh2 to latest version (v1.9.0) which adds support for ECDSA and ED25519 keys.
@simsekgokhan
Copy link
Collaborator

simsekgokhan commented Sep 4, 2020

Hi, on Windows & macOS, we have upgraded our SSH library to the latest version (libssh2 v1.9.0 - Jun/2019) and it supports ECDSA and Ed25519 keys. Also during development, we saw that the upgrade fixed some problematic cases.
I hope Robo 3T 1.4 will fix some of your problems -> Robo 3T 1.4

Please let us know.
And please also see: #1189 (comment) and #1590 (comment)

@jameshulse
Copy link

jameshulse commented Nov 11, 2020

Any word on when this fix will be coming to the linux version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Robo 3T 1.4
Awaiting triage
Development

No branches or pull requests

3 participants