Robomongo: Failed to create SSH tunnel (Robo 3T - 1.2) on ubuntu

[claytonmarinho]

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]

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

[yoerivdm]

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]

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]

Have the same issue.

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

[madmuffin1]

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[34257]: debug1: Forked child 9398. 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]

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]

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]

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]

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

[KarunaGovind]

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]

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]

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

[ReinaldoTeixeira]

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]

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.

[TomasTokaMrazek]

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]

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]

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