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 to $IP #1189

Open
paulbrie opened this issue Sep 19, 2016 · 51 comments
Open

Failed to create SSH tunnel to $IP #1189

paulbrie opened this issue Sep 19, 2016 · 51 comments

Comments

@paulbrie
Copy link

@paulbrie paulbrie commented Sep 19, 2016

Hi, I have the following error on my Mac (OS X Yosemite - 10.10.5 )

Error:
Resource temporarily unavailable. Authentication by key (/Users/paulbrie/.ssh/id_rsa) failed (Error -16). (Error #35)

It is not a key issue because it works in the terminal. I also tried with a key which works for a colleague: same result. Can you give me more details about the issue and its origin?

Thanks,
Paul

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Sep 20, 2016

Hi @paulbrie , thanks a lot for reporting the issue.
Unfortunately, this issue has been reported before, we have done many testing with different conditions and servers, but we are unable to reproduce this problem in our labs.

Our initial investigation showed that this issue is related to maximum process count limitation of MAC. But we are unable to confirm. (If this is the root cause, issue should be gone after system reboot)

We will be more than happy to investigate your problem as "critical" priority if you can give us as much as information you can. Firstly, can you tell us Robomongo version, OS version of your remote server and is this issue reproduced all the time or sometimes? It is also good to know if password authentication has the same problem.

Loading

@tanushshukla
Copy link

@tanushshukla tanushshukla commented Nov 21, 2016

I can help you out with the info. I have all environments setup at my place. For now, I've tried with two laptops on windows 8.1 and 10 and both are giving me the same issue. I know the key is right because Mongochef is working fine on both machines.

RoboMongo version 0.9.0.
OS of remote server -> Ubuntu 16 LTS.
Issue reproduced all the time or sometimes -> All the times.
password authentication -> Can't check as I've disabled it.

The other thing if it matters is that the key was generated with 4096 bits rather than 2048.
Also, I can share you the key and password with you guys of my test environment if that helps.

Loading

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Nov 21, 2016

Hi @hellrokr , thanks a lot for reporting the problem and trying to help. We appreciate.
Yes, if you can share the key that would be awesome. If we can reproduce this issue all the times, solving will be much easier.

Note:
Here is another interesting finding about keys: #1125 (comment)

Loading

@macpham
Copy link

@macpham macpham commented Apr 7, 2017

I can also reproduce this problem with RoboMongo 1.0.0 RC1 on Mac OSX El Capitan.

My key is also working with MongoHub to the same server.

Loading

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Apr 11, 2017

Hi @macpham , thanks for reporting the problem.

Any chance you are using *.ppk key files? Or any detail about your key format will be useful, seems like that's the problem (Robomongo does not support all formats), but we did not fully identify which ones yet. More: #1125 (comment)

Loading

@irworks
Copy link

@irworks irworks commented Jun 9, 2017

Just want to confirm that this issue occurred to me too. After using the same connection in Robomongo for weeks it suddenly stopped working.

Error: Resource temporarily unavailable. Authentication by key (/Users/irworks/.ssh/id_rsa) failed (Error -18). (Error #35)

Robomongo 1.0.0 on macOS Sierra.

I managed to work around this issue by changing the username which I use to connect via ssh, changing back to the initial user repeats the issue.

Loading

@crebuh
Copy link

@crebuh crebuh commented Jun 16, 2017

I've got the same error with Robomongo 0.9.0 and also the new Robo3T 1.1. The funny thing is that I can cannot via ssh to amazon servers, but not to our servers on linode. Any idea?

Loading

@simsekgokhan simsekgokhan added this to Todo in SSH Issues Jun 22, 2017
@simsekgokhan simsekgokhan added this to the SSH Connection Problems milestone Jun 26, 2017
@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Jul 5, 2017

Hi @crebuh , thanks for reporting the problem.
The root cause of this issue still remains a secret and under investigation. We are unable to reproduce in our systems.

There has been very interesting and simple solutions reported like using a new username, key/password or key type solved their problems.

Loading

@waxyhexagon
Copy link

@waxyhexagon waxyhexagon commented Oct 12, 2017

Apologies for reviving a somewhat dead thread. It's the top result in google.

For those who are googling and still looking for a response (Like me), the issue and answer somewhat lies in here. As @simsekgokhan has mentioned, if you are using a *.ppk file the connection will fail. The resolution (if using putty and putty gen) is to open up the ppk file in putty gen and save it as an openssh file. Do not force the new file format as that will also fail. It needs to be the general openssh format.

Instructions:
Open putty gen
Select "Load" and select your *.ppk
Go to the "Conversions" drop down
Export OpenSSH --NOT the new format
Use the new file generated to connect.

Loading

@agarcian
Copy link

@agarcian agarcian commented Dec 5, 2017

We are experiencing this issue as well. We are using Robo 3T 1.1.1 and when connecting to a server, the SSH channel cannot be established, however it works well from Terminal (Mac OS High Sierra)

This was working before, and one day stopped working. Other servers still connect OK. Something about this specific server doesn't like it.
Private key is a pem file.

Loading

@Chunlin-Li
Copy link

@Chunlin-Li Chunlin-Li commented Dec 6, 2017

See the same error on Mac OS Sierra. Robo 3T 1.1.1
use ssh command to target server by rsa key works well. Only Robo connect failed.
I check the ip, port, username, and key path again and again. I'm sure the settings are correct.

log :

2:06:57 PM Error: Resource temporarily unavailable. Error when starting up SSH session: -8
. (Error #35)

Loading

@stephan-nordnes-eriksen

I am seeing the same issue on Robo 3T 1.1.1 on MacOS High Sierra as @Chunlin-Li and @agarcian are reporting.

Strangely enough, the same exact connection settings works in Studio 3T. This might be some sort of clue to the mystery?

Loading

@simsekgokhan simsekgokhan removed this from Todo in SSH Issues Dec 11, 2017
@simsekgokhan simsekgokhan added this to Ready-For-Testing in Robo 3T 1.2 Dec 20, 2017
@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Dec 21, 2017

Hi All, sorry for the inconvenience and for the delay. We have an SSH enhancement to fix this problem and some other SSH issues. But, we cannot verify our fix for the problem in this ticket, since we are still unable to reproduce this problem in our systems. We are asking your help to test the following beta for us (fingers crossed).

Robo 3T 1.2 - Beta

Note:
Please also be aware that Putty (*.ppk) key files cause problems and not supported. Robo supports OpenSSH format. Steps to convert ppk to OpenSSH is here #484 (comment).

Loading

@simsekgokhan simsekgokhan added this to SSH failure (Resources temporarily unavailable) in Robo 3T 1.2 - Beta Testing Dec 21, 2017
@stephan-nordnes-eriksen
Copy link

@stephan-nordnes-eriksen stephan-nordnes-eriksen commented Dec 21, 2017

That version works for me at least, on MacOS High Sierra 10.13.2 (17C88) 🎉

Thanks a lot!

Loading

@agarcian
Copy link

@agarcian agarcian commented Dec 22, 2017

Loading

@Chunlin-Li
Copy link

@Chunlin-Li Chunlin-Li commented Dec 22, 2017

@simsekgokhan Thank you! That version works for me.

Loading

@mephi1984
Copy link

@mephi1984 mephi1984 commented Dec 22, 2017

This solved for me too, thanks!
Windows 10
Amazon Linux 2 on remote server

Loading

@davisford
Copy link

@davisford davisford commented Dec 24, 2017

This just happened to me too. Actually corroborated also with a co-worker. Our servers are in EC2. We use Robo 3T probably daily for years and the SSH tunnel has always just worked. Yesterday we had an issue where I had to step down our Primary in the replica set and elect a new primary, so our replica set status got jogged around a bit, but IP addresses remained the same.

The other thing I did was a sudo yum update on the servers, so it's very likely openssh or other related libs probably got upgraded.

Since that time, we can no longer tunnel with Robo 3T, but we can still connect just fine using Mac Terminal.

My guess is something changed in the openssh server libs and people only see it if they get that update, which causes the problem. Would have to scour logs on server side to see if we can track something down.

We use Amazon Linux -- could test by spawning a brand new Amazon Linux AMI, running sudo yum update and install mongo on it, and see if you can connect. My guess is some openssh lib update probably broke the integration.

Edit: Robo 3T 1.2 Beta fix posted above also fixes the issue for me.

Loading

@lscarneiro
Copy link

@lscarneiro lscarneiro commented Dec 12, 2018

Hi,
I'm on macOS Mojave (10.14.1)
Robo 3T 1.2.1

using private key in openssh format

-----BEGIN OPENSSH PRIVATE KEY----- 
....
-----END OPENSSH PRIVATE KEY-----

And I'm getting:

Failed to create SSH tunnel to $IP

Error:
Resource temporarily unavailable. Authentication by key (/path/pvt_key) failed (Error -16). (Error #35)

The key was not "converted" from PuTTY, it was generated directly to ssh-keygen locally, and I can use it normally to connect to my server hosted on Google Cloud.

Any ideas?

(I see a lot of issues related with PuTTY and with the solution being to use 1.2 Beta, but I'm on a later version with a OpenSSH key already, so...)

Loading

@lscarneiro
Copy link

@lscarneiro lscarneiro commented Dec 13, 2018

After a lot of pain, I finally achieved connection with Robo 3T through SSH Tunnel.

The SO post that helped me was this one

Basically, you should use a private key generated through openssl instead of ssh-keygen (why? IDK)

Generate the private key:

openssl genpkey -algorithm RSA -out private.pem

Then, get the public key to add to your server .ssh/authorized_keys file with:

ssh-keygen -y -f private.pem

Then, finally connect Robo 3T using this private.pem key file and voilá

Loading

@heikkijuntunen
Copy link

@heikkijuntunen heikkijuntunen commented Jan 8, 2020

I fixed this by using following methos in my MacOS (10.15.2). First create copy of the existing OPENSSH private key:
cp -p .ssh/id_rsa .ssh/id_rsa.pem

Then convert copy into PEM private key:
ssh-keygen -p -m PEM -f .ssh/id_rsa.pem

And then using id_rsa.pem instead of id_rsa as private key in Robo 3T I didn't get the error message anymore

Loading

@sattellite
Copy link

@sattellite sattellite commented Jan 20, 2020

@heikkijuntunen thank you for workaround solution. It helps!

Loading

@anand-k-p
Copy link

@anand-k-p anand-k-p commented Jan 22, 2020

After a lot of pain, I finally achieved connection with Robo 3T through SSH Tunnel.

The SO post that helped me was this one

Basically, you should use a private key generated through openssl instead of ssh-keygen (why? IDK)

Generate the private key:

openssl genpkey -algorithm RSA -out private.pem

Then, get the public key to add to your server .ssh/authorized_keys file with:

ssh-keygen -y -f private.pem

Then, finally connect Robo 3T using this private.pem key file and voilá

This worked for me - thanks @lscarneiro! - BUT... I had to ensure that SSH "AllowTcpForwarding" was set to "yes" on the server. Took a while to figure this out so I wanted to share this out.

So... Double check your sshd_config configuration so that:

AllowTcpForwarding no (if it is no) is changed to

AllowTcpForwarding yes

Hope this helps!

Loading

@beliga44
Copy link

@beliga44 beliga44 commented Mar 19, 2020

I fixed this by using following methos in my MacOS (10.15.2). First create copy of the existing OPENSSH private key:
cp -p .ssh/id_rsa .ssh/id_rsa.pem

Then convert copy into PEM private key:
ssh-keygen -p -m PEM -f .ssh/id_rsa.pem

And then using id_rsa.pem instead of id_rsa as private key in Robo 3T I didn't get the error message anymore

It's works like a magic.. :)

Loading

@solancer
Copy link

@solancer solancer commented Apr 26, 2020

After a lot of pain, I finally achieved connection with Robo 3T through SSH Tunnel.

The SO post that helped me was this one

Basically, you should use a private key generated through openssl instead of ssh-keygen (why? IDK)

Generate the private key:

openssl genpkey -algorithm RSA -out private.pem

Then, get the public key to add to your server .ssh/authorized_keys file with:

ssh-keygen -y -f private.pem

Then, finally connect Robo 3T using this private.pem key file and voilá

This is the only solution that worked!

Loading

@dashko
Copy link

@dashko dashko commented May 6, 2020

None of the provided solutions worked in Ubuntu.

Loading

@shivarajnaidu
Copy link

@shivarajnaidu shivarajnaidu commented Jun 5, 2020

Error:
Resource temporarily unavailable. Error when starting up SSH session: -8
. (Error #11)

I am getting this with EC2

Loading

@ghost
Copy link

@ghost ghost commented Jun 15, 2020

Resource temporarily unavailable. Error when starting up SSH session: -8

My MongoDB replica set is on Azure VMs, trying to access it from my computer (Windows 10), tried all kinds of different private keys but nothing worked. Works with Studio 3T no problem.

Edit:
Got a bit further with this problem, at least now it can connect to the SSH server.
Put my SSH server in debug mode, noticed in the logs this error:
kex protocol error: type 30 seq 1 [preauth]

This is a testing machine so I got all available Kex algorithms with: ssh -Q kex | paste -d , -s -
Added that list in /etc/ssh/sshd_config: KexAlgorithms $my_list
So my guess is that Robo 3T SSH module's implementation is using some deprecated key exchange algorithm.

Now I'm just stuck at Error: Establish connection failed. No member of the set is reachable. Reason: Connect failed.

Loading

@imkane
Copy link

@imkane imkane commented Jul 17, 2020

This is happening to me now with a new connection in Robo. Terminal SSH works fine, and MongoDB Compass works fine with all the same connection settings.

Failed to create SSH tunnel to myhostname:22.

Error:
Resource temporarily unavailable. Error when starting up SSH session: -8
. (Error #11)

Loading

@nikhilmuz
Copy link

@nikhilmuz nikhilmuz commented Aug 28, 2020

I fixed this by using following methos in my MacOS (10.15.2). First create copy of the existing OPENSSH private key:
cp -p .ssh/id_rsa .ssh/id_rsa.pem

Then convert copy into PEM private key:
ssh-keygen -p -m PEM -f .ssh/id_rsa.pem

And then using id_rsa.pem instead of id_rsa as private key in Robo 3T I didn't get the error message anymore

Works. :) Thanks

Loading

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Sep 4, 2020

Hi all, 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

More about this topic in the blog post:
SSH upgrade (libssh2 1.9.0 - Jun/2019, Windows & macOS only)
https://blog.robomongo.org/robo-3t-1-4/#b2

Loading

@simsekgokhan
Copy link
Collaborator

@simsekgokhan simsekgokhan commented Sep 4, 2020

And thanks a lot lot @lscarneiro #1189 (comment) and @jasontrask #1590 (comment) for your contributions.

Loading

@Heathland
Copy link

@Heathland Heathland commented Sep 4, 2020

Hi @simsekgokhan , I can confirm it's working.
Thank you for the help and this great project!

Loading

@reetp
Copy link

@reetp reetp commented Sep 21, 2020

After quite a bit of testing this morning connecting my Xubuntu Bionic (18.04) desktop to a CentOS 7 based sshd server it looks like the issue is to do with robo3t still wanting to use outdated sha1 ciphers. Recent servers will disable them by default.

Server:

rpm -qa | grep libssh

libssh2-1.8.0-3.el7.x86_64

I'm using a straightforward id_rsa key generated with ssh-keygen.

If I add either of the following to my sshd_config file robo3t can connect. Remove them and it fails every time.

Works if added:
diffie-hellman-group14-sha1
diffie-hellman-group1-sha1

Fails if added:
diffie-hellman-group-exchange-sha1

Success log on server:

2020-09-21 16:21:57.639356500 debug1: Client protocol version 2.0; client software version libssh2_1.7.0_DEV
2020-09-21 16:21:57.639433500 debug1: no match: libssh2_1.7.0_DEV
2020-09-21 16:21:57.639515500 debug1: Local version string SSH-2.0-OpenSSH_7.4
2020-09-21 16:21:57.639645500 debug1: Enabling compatibility mode for protocol 2.0
2020-09-21 16:21:57.641518500 debug1: SELinux support disabled [preauth]
2020-09-21 16:21:57.641649500 debug1: permanently_set_uid: 74/74 [preauth]
2020-09-21 16:21:57.641753500 debug1: list_hostkey_types: ssh-dss,ssh-rsa,rsa-sha2-512,rsa-sha2-256 [preauth]
2020-09-21 16:21:57.642050500 debug1: SSH2_MSG_KEXINIT sent [preauth]
2020-09-21 16:21:57.642195500 debug1: SSH2_MSG_KEXINIT received [preauth]
2020-09-21 16:21:57.642292500 debug1: kex: algorithm: diffie-hellman-group14-sha1 [preauth]
2020-09-21 16:21:57.642383500 debug1: kex: host key algorithm: ssh-rsa [preauth]
2020-09-21 16:21:57.642424500 debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
2020-09-21 16:21:57.642551500 debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
2020-09-21 16:21:57.642646500 debug1: kex: diffie-hellman-group14-sha1 need=32 dh_need=32 [preauth]
2020-09-21 16:21:57.643048500 debug1: kex: diffie-hellman-group14-sha1 need=32 dh_need=32 [preauth]
2020-09-21 16:21:57.646098500 debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
2020-09-21 16:21:57.652163500 debug1: rekey after 4294967296 blocks [preauth]
2020-09-21 16:21:57.652165500 debug1: SSH2_MSG_NEWKEYS sent [preauth]
2020-09-21 16:21:57.652165500 debug1: expecting SSH2_MSG_NEWKEYS [preauth]
2020-09-21 16:21:57.653990500 debug1: SSH2_MSG_NEWKEYS received [preauth]
2020-09-21 16:21:57.653991500 debug1: rekey after 4294967296 blocks [preauth]
2020-09-21 16:21:57.653992500 debug1: KEX done [preauth]
2020-09-21 16:21:57.695408500 debug1: userauth-request for user root service ssh-connection method none [preauth]
2020-09-21 16:21:57.695409500 debug1: attempt 0 failures 0 [preauth]
2020-09-21 16:21:57.697591500 debug1: PAM: initializing for "root"
2020-09-21 16:21:57.702523500 debug1: PAM: setting PAM_RHOST to "pc-00062.local.net"
2020-09-21 16:21:57.702575500 debug1: PAM: setting PAM_TTY to "ssh"
2020-09-21 16:21:57.702656500 debug1: userauth-request for user root service ssh-connection method publickey [preauth]
2020-09-21 16:21:57.702694500 debug1: attempt 1 failures 0 [preauth]
2020-09-21 16:21:57.702734500 debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:WeR8Jg0aacxvfW94RjNJ5VX/va50ZoQ7vQJad4lalws [preauth]
2020-09-21 16:21:57.702835500 debug1: temporarily_use_uid: 0/0 (e=0/0)
2020-09-21 16:21:57.703258500 debug1: trying public key file /root/.ssh/authorized_keys
2020-09-21 16:21:57.703259500 debug1: fd 4 clearing O_NONBLOCK
2020-09-21 16:21:57.703491500 debug1: matching key found: file /root/.ssh/authorized_keys, line 1 RSA SHA256:WeR8Jg0aacxvfW94RjNJ5VX/va50ZoQ7vQJad4lalws
2020-09-21 16:21:57.703492500 debug1: restore_uid: 0/0
2020-09-21 16:21:57.703812500 Postponed publickey for root from 192.168.10.62 port 37312 ssh2 [preauth]
2020-09-21 16:21:57.708998500 debug1: userauth-request for user root service ssh-connection method publickey [preauth]
2020-09-21 16:21:57.709174500 debug1: attempt 2 failures 0 [preauth]
2020-09-21 16:21:57.709175500 debug1: temporarily_use_uid: 0/0 (e=0/0)
2020-09-21 16:21:57.709176500 debug1: trying public key file /root/.ssh/authorized_keys
2020-09-21 16:21:57.709176500 debug1: fd 4 clearing O_NONBLOCK
2020-09-21 16:21:57.709176500 debug1: matching key found: file /root/.ssh/authorized_keys, line 1 RSA SHA256:WeR8Jg0aacxvfW94RjNJ5VX/va50ZoQ7vQJad4lalws
2020-09-21 16:21:57.709177500 debug1: restore_uid: 0/0
2020-09-21 16:21:57.709804500 debug1: do_pam_account: called
2020-09-21 16:21:57.710651500 Accepted publickey for root from 192.168.10.62 port 37312 ssh2: RSA SHA256:WeR8Jg0aacxvfW94RjNJ5VX/va50ZoQ7vQJad4lalws
2020-09-21 16:21:57.710697500 debug1: monitor_child_preauth: root has been authenticated by privileged process
2020-09-21 16:21:57.713123500 debug1: monitor_read_log: child log fd closed
2020-09-21 16:21:57.713314500 debug1: SELinux support disabled
2020-09-21 16:21:57.713315500 debug1: PAM: establishing credentials
2020-09-21 16:21:57.723913500 debug1: rekey after 4294967296 blocks
2020-09-21 16:21:57.723913500 debug1: rekey after 4294967296 blocks
2020-09-21 16:21:57.723914500 debug1: ssh_packet_set_postauth: called
2020-09-21 16:21:57.723914500 debug1: Entering interactive session for SSH2.
2020-09-21 16:21:57.723915500 debug1: server_init_dispatch
2020-09-21 16:21:57.723915500 debug1: server_input_channel_open: ctype direct-tcpip rchan 0 win 2097152 max 32768
2020-09-21 16:21:57.723916500 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 32985, target 127.0.0.1 port 27017
2020-09-21 16:21:57.723941500 debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:27017) in progress, fd=8
2020-09-21 16:21:57.723941500 debug1: channel 0: new [direct-tcpip]
2020-09-21 16:21:57.723942500 debug1: server_input_channel_open: confirm direct-tcpip
2020-09-21 16:21:57.723942500 debug1: channel 0: connected to 127.0.0.1 port 27017
2020-09-21 16:21:57.970008500 debug1: server_input_channel_open: ctype direct-tcpip rchan 1 win 2097152 max 32768
2020-09-21 16:21:57.970010500 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 32985, target 127.0.0.1 port 27017
2020-09-21 16:21:57.970511500 debug1: connect_next: host 127.0.0.1 ([127.0.0.1]:27017) in progress, fd=9
2020-09-21 16:21:57.970512500 debug1: channel 1: new [direct-tcpip]
2020-09-21 16:21:57.970513500 debug1: server_input_channel_open: confirm direct-tcpip
2020-09-21 16:21:57.970513500 debug1: channel 1: connected to 127.0.0.1 port 27017
2020-09-21 16:22:02.025752500 debug1: channel 0: free: direct-tcpip, nchannels 2
2020-09-21 16:22:02.068115500 Received disconnect from 192.168.10.62 port 37312:11: Client disconnecting normally
2020-09-21 16:22:02.068116500 Disconnected from 192.168.10.62 port 37312

Fail log on server

2020-09-21 16:24:04.473781500 Connection from 192.168.10.62 port 37362 on 192.168.10.210 port 2222
2020-09-21 16:24:04.473986500 debug1: Client protocol version 2.0; client software version libssh2_1.7.0_DEV
2020-09-21 16:24:04.474012500 debug1: no match: libssh2_1.7.0_DEV
2020-09-21 16:24:04.474012500 debug1: Local version string SSH-2.0-OpenSSH_7.4
2020-09-21 16:24:04.474013500 debug1: Enabling compatibility mode for protocol 2.0
2020-09-21 16:24:04.475724500 debug1: SELinux support disabled [preauth]
2020-09-21 16:24:04.475902500 debug1: permanently_set_uid: 74/74 [preauth]
2020-09-21 16:24:04.476009500 debug1: list_hostkey_types: ssh-dss,ssh-rsa,rsa-sha2-512,rsa-sha2-256 [preauth]
2020-09-21 16:24:04.476184500 debug1: SSH2_MSG_KEXINIT sent [preauth]
2020-09-21 16:24:04.476385500 debug1: SSH2_MSG_KEXINIT received [preauth]
2020-09-21 16:24:04.476519500 debug1: kex: algorithm: diffie-hellman-group-exchange-sha1 [preauth]
2020-09-21 16:24:04.476615500 debug1: kex: host key algorithm: ssh-rsa [preauth]
2020-09-21 16:24:04.476679500 debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
2020-09-21 16:24:04.476778500 debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none [preauth]
2020-09-21 16:24:04.476845500 debug1: kex: diffie-hellman-group-exchange-sha1 need=32 dh_need=32 [preauth]
2020-09-21 16:24:04.477375500 debug1: kex: diffie-hellman-group-exchange-sha1 need=32 dh_need=32 [preauth]
2020-09-21 16:24:04.477667500 debug1: expecting SSH2_MSG_KEX_DH_GEX_REQUEST [preauth]
2020-09-21 16:24:04.477737500 kex protocol error: type 30 seq 1 [preauth]

#1754 might be suffering the same thing

Loading

@tienthanh2509
Copy link

@tienthanh2509 tienthanh2509 commented Dec 23, 2020

Some auth.log in my server

Dec 23 10:45:47 ip-10-0-1-35 sshd[3754]: Connection closed by xx.xx.xx.xx port 35246 [preauth]
Dec 23 10:46:30 ip-10-0-1-35 sshd[3757]: Received disconnect from xx.xx.xx.xx port 58636:11:  [preauth]
Dec 23 10:46:30 ip-10-0-1-35 sshd[3757]: Disconnected from authenticating user root 221.181.185.200 port 58636 [preauth]
Dec 23 10:46:46 ip-10-0-1-35 sshd[3759]: error: kex protocol error: type 30 seq 1 [preauth]

Robot3T tunnel failed but ssh cmd still work


update:

I think Robot3T use old encrypt algorithms no longer support in the openssh-server

Workaround by add bellow config to sshd-config file

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1

Loading

@Rush
Copy link

@Rush Rush commented Aug 3, 2021

Workaround by add bellow config to sshd-config file
Unfortunately my SSHD fails to start if I add these extra algorithms. And

Also it seems it's asking for trouble, opening a security loophole.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Robo 3T 1.2
Ready-For-Testing
Robo 3T 1.2 - Beta Testing
SSH failure (Resources temporarily un...
Linked pull requests

Successfully merging a pull request may close this issue.

None yet