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

Failed to create SSH tunnel (Robo 3T - 1.2) on ubuntu #1590

Open
claytonmarinho opened this issue Oct 23, 2018 · 20 comments
Open

Failed to create SSH tunnel (Robo 3T - 1.2) on ubuntu #1590

claytonmarinho opened this issue Oct 23, 2018 · 20 comments
Labels

Comments

@claytonmarinho
Copy link

claytonmarinho commented Oct 23, 2018

Failed to create SSH tunnel to xxx.xxx.xxx.xxx:22.
Error:
Permission denied. Authentication by key (file.pem) failed (Error -16). (Error #13)

I can connect without problem by ssh command or any other GUI - Why didn't work on Robo3T?

Ubuntu 18.04.1 LTS

Thanks.

@NGTmeaty
Copy link

NGTmeaty commented Oct 24, 2018

Sure it's the right key? It's working for me.

@yoerivdm
Copy link

yoerivdm commented Nov 2, 2018

Hey, I got the same issue.
Just bought a new macbook pro, installed mojavo, robo3T.

Failed to create SSH tunnel to xxxx:22.
Error:
Resource temporarily unavailable. Authentication by key (/Users/xxxxxx/.ssh/id_rsa) failed (Error -16). (Error #35)

I can still connect with my older macbookpro and my iMac, both upgraded to Mojave.
ServerSide is running Ubuntu 18.04 (have a second ubuntu 16.04 server which fails the same)

I think it's a general problem with ssh authentication in third-party apps. I can connect via terminal to the server without password without any problem. Connections with either Robo3T, CommanderOne or Cyberduck all fails.

Any directions?

@berniey
Copy link

berniey commented Nov 11, 2018

I have same issue too. SSH connectivity to the mongo server works with using ssh command ssh -i my_key my_name@my_host!

From:
MacOS 10.13.3
Robo 3T: 1.2.1

To:
Ubuntu 18.04.1 LTS
MongoDB 4.0.2

Found that the ssh tunnel will work with default rsa key setting ssh -t rsa, but failed when increasing key length.

@grandkrav
Copy link

grandkrav commented Dec 5, 2018

Have the same issue.

Permission denied. Authentication by key (xxx/id_rsa) failed (Error -16). (Error #13)

@madmuffin1
Copy link

madmuffin1 commented Dec 11, 2018

We're facing a similar problem, on a rather fresh Ubuntu 18.04.1 (client). It seems the client hangs up after the successful key exchange before even trying to authenticate.

We raised the log level on the server side to debug to get this output. For a working client the output is identical up to the point where the connection is closed.

Dec 11 13:23:49 server sshd[9398]: debug1: Set /proc/self/oom_score_adj to 0
Dec 11 13:23:49 server sshd[9398]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Dec 11 13:23:49 server sshd[9398]: debug1: inetd sockets after dupping: 3, 3
Dec 11 13:23:49 server sshd[9398]: Connection from 1.2.3.4 port 41580 on 10.10.10.10 port 22
Dec 11 13:23:49 server sshd[9398]: debug1: Client protocol version 2.0; client software version libssh2_1.7.0_DEV
Dec 11 13:23:49 server sshd[9398]: debug1: no match: libssh2_1.7.0_DEV
Dec 11 13:23:49 server sshd[9398]: debug1: Enabling compatibility mode for protocol 2.0
Dec 11 13:23:49 server sshd[9398]: debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.6
Dec 11 13:23:49 server sshd[9398]: debug1: permanently_set_uid: 109/65534 [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: list_hostkey_types: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: SSH2_MSG_KEXINIT received [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: kex: algorithm: diffie-hellman-group14-sha1 [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: kex: host key algorithm: ssh-rsa [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: rekey after 4294967296 blocks [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: rekey after 4294967296 blocks [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: KEX done [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: userauth-request for user ubuntu service ssh-connection method none [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: attempt 0 failures 0 [preauth]
Dec 11 13:23:49 server sshd[9398]: Connection closed by 1.2.3.4 port 41580 [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: do_cleanup [preauth]
Dec 11 13:23:49 server sshd[9398]: debug1: monitor_read_log: child log fd closed
Dec 11 13:23:49 server sshd[9398]: debug1: do_cleanup
Dec 11 13:23:49 server sshd[9398]: debug1: Killing privsep child 9399
Dec 11 13:23:49 server sshd[9398]: debug1: audit_event: unhandled event 12

@madmuffin1
Copy link

madmuffin1 commented Dec 11, 2018

P.S.: we figured out that the not working clients private key was stored in the new openssh private key format (using openssh-keygen -o) instead of the rsa private key format. After generating and authorizing a new key in the standard rsa format, connecting was possible. Apparently libssh1.7 (which is used in robo3t) can not handle this new keyfile format.

The biggest problem is IMHO apparently the error message, which does not hint anywhere near this underlying issue.

@jasontrask
Copy link

jasontrask commented Mar 24, 2019

This solved it for me, thanks @madmuffin1! I'd created the key using ssh-keygen on MacOS Mojave 10.14.3, which now seems to use the new OpenSSH format.

Adding the -m PEM flag to the keygen command is what's needed to create the key in the previous RSA format. I'm now able to connect via an SSH tunnel through Robo 3T again 🥳.

e.g. ssh-keygen -m PEM -t rsa

@rafaelmaeuer
Copy link

rafaelmaeuer commented Mar 24, 2019

I have a similar issue on OS X Mojave with Robo 3T 1.2. I recently upgraded my old RSA key to the newest ed25519 format as recommended here: Link. It seems Robo 3T lacks support for newer SSH standards, is this planned, as RSA is only considered safe with 3072 Bit or more.

@jdlourenco
Copy link

jdlourenco commented May 30, 2019

I'm also unable to use ssh forwarding within rob 3t with my ed25519 key. Any plans to support it?

@KarunaGovind
Copy link

KarunaGovind commented Jul 16, 2019

If it helps anyone, I found out that if Robo 3T is installed using snap, ssh authentication does not work. I had to download the tar file and run it using that in order for SSH to work.

I'm on a clean install of Ubuntu 19.04 and Robo 3T 1.3.1.

@marcusorjames
Copy link

marcusorjames commented Aug 13, 2019

If it helps anyone, I found out that if Robo 3T is installed using snap, ssh authentication does not work. I had to download the tar file and run it using that in order for SSH to work.

I'm on a clean install of Ubuntu 19.04 and Robo 3T 1.3.1.

Yup this was the problem, god damn snap always has problems.

Ubuntu 18.04 had snap installed Robo 3T 1.3.1, wouldn't connect to ssh. Removed the snap, manually downloaded, now works fine. Thanks @KarunaGovind

@yooneskh
Copy link

yooneskh commented Oct 8, 2019

Installing via snap was the problem for me too ...

@reinaldoteixeira
Copy link

reinaldoteixeira commented Jan 28, 2020

This solved it for me, thanks @madmuffin1! I'd created the key using ssh-keygen on MacOS Mojave 10.14.3, which now seems to use the new OpenSSH format.

Adding the -m PEM flag to the keygen command is what's needed to create the key in the previous RSA format. I'm now able to connect via an SSH tunnel through Robo 3T again 🥳.

e.g. ssh-keygen -m PEM -t rsa

this solved my problem, thanks!

@minhna
Copy link

minhna commented Apr 27, 2020

If it helps anyone, I found out that if Robo 3T is installed using snap, ssh authentication does not work. I had to download the tar file and run it using that in order for SSH to work.

I'm on a clean install of Ubuntu 19.04 and Robo 3T 1.3.1.

It happens on Ubuntu 20.04.
Thank you for your help.

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.
@TomasTokaMrazek
Copy link

TomasTokaMrazek commented Jul 9, 2020

For those who are using snap, copying PEM file into ~/snap/robo3t-snap/4 solved the issue. Apparently the snap package has some trouble accessing files outside of it's directory.

@drorventura
Copy link

drorventura commented Jul 29, 2020

For those who are using snap, copying PEM file into ~/snap/robo3t-snap/4 solved the issue. Apparently the snap package has some trouble accessing files outside of it's directory.

snap can't access hidden folders
https://askubuntu.com/questions/1039850/snap-packages-cant-use-my-ssh-key

@fcrvsm
Copy link

fcrvsm commented May 20, 2021

I had the same error, but because of a small, but difficult to identify, problem: I had a blank space after the SSH address. That was enough to produce the error: "Failed to create SSH tunnel to XX.XXX.XXX.XX :22. Error: Failed to get address info".

@VikumPerera-Kognitiv
Copy link

VikumPerera-Kognitiv commented Sep 17, 2021

This solved it for me, thanks @madmuffin1! I'd created the key using ssh-keygen on MacOS Mojave 10.14.3, which now seems to use the new OpenSSH format.

Adding the -m PEM flag to the keygen command is what's needed to create the key in the previous RSA format. I'm now able to connect via an SSH tunnel through Robo 3T again partying_face.

e.g. ssh-keygen -m PEM -t rsa

This solved my problem

@Getitdan
Copy link

Getitdan commented Feb 22, 2022

For those that have used: "PuTTY Key Generator" to generate the SSH keys: you should export an OpenSSH compatible file.

At the top of the PuTTY Key Generator click on: Conversion > Export OpenSSH key, and save your key: "key.openssh". Now import this file for authentication, and you are done.

@sidsaxena0
Copy link

sidsaxena0 commented Jul 8, 2022

For those that have used: "PuTTY Key Generator" to generate the SSH keys: you should export an OpenSSH compatible file.

At the top of the PuTTY Key Generator click on: Conversion > Export OpenSSH key, and save your key: "key.openssh". Now import this file for authentication, and you are done.

Thanks @Getitdan it helped me. It sad that this issue still exist in Studio 3T too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests