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
Server crashes before NET_SSH2_MSG_KEXDH_REPLY #1992
Comments
First, with a server identification string of SSH-2.0-OpenSSH_6.9 implementing a workaround specifically for Juniper switches is going to hard. It might still be possible to implement a workaround (eg. what I did for https://bugzilla.mindrot.org/show_bug.cgi?id=1291 was to make it so that if one of the problem algorithms is being used when a packet isn't able to be correctly decrypted that it tries to reconnect without the problem algorithms [see the Your post shows a cipher suite but it's unclear if that cipher suite is for a successful connection or a failing one. But like does it fail if client_to_server/crypt is a specific algorithm? Does every algorithm need to be a specific algorithm for it to fail? idk If you were to share with me the IP address of the machine (I wouldn't need an account on that machine) to brute force different cipher suites I could do that myself. If you are able to do this you can email the info to terrafrost@gmail.com. SSH logs would also help. There are two main ways to get SSH log: Ephemeral LoggingYou can get the SSH logs by creating a new temporary SSH instance with Persistent Loggingidk if you can edit the
Once you do that you'll need to restart SSH ( As https://serverfault.com/a/1130653 discusses, logs are stored by default to the AUTH SyslogFacility, eg. /var/log/auth.log. You can, however, change that by adding this to your sshd_config, as well:
You'd then want to modify
You'd then need to restart rsyslog ( |
Sorry for the very delayed response. Sadly I won't be able to give you access to the server. I appreciate you looking into this, but considering how much of an edge case this is, I think the workarounds are sufficient:
I'll be closing this off, maybe this helps someone somewhen! |
Recently upgraded a web application, moving from phpseclib1 to phpseclib3 (running
phpseclib/phpseclib 3.0.37
).Using the exact same code, I am now no longer able to successfully establish a connection to some Juniper switches, unless I explicitly call
setPreferredAlgorithms
.The connection fails after
NET_SSH2_MSG_KEXDH_INIT
and beforeNET_SSH2_MSG_KEXDH_REPLY
with:
phpseclib3\Exception\ConnectionClosedException No data received from server.
sshd[3570]: fatal: ssh_dispatch_run_fatal: Connection to 1.2.3.4: unexpected internal error [preauth]
Using the algorithms from a successful connection to another switch via
getAlgorithmsNegotiated
and setting them viasetPreferredAlgorithms
, allows me to connect to the device, example below.I assume this to be an issue on the server side, but would appreciate any feedback. Thank you!
Log of the failed connection:
The text was updated successfully, but these errors were encountered: