Server crashes before NET_SSH2_MSG_KEXDH_REPLY

[esljaz]

Server crashes before NET_SSH2_MSG_KEXDH_REPLY

[terrafrost]

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 bad_algorithm_candidate method in SSH2.php) but to decide if that'd be appropriate approach I'd need more info - the SSH logs and what the specific algorithm that's failing is.

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 [email protected].

SSH logs would also help. There are two main ways to get SSH log:

Ephemeral Logging

You can get the SSH logs by creating a new temporary SSH instance with sudo /usr/sbin/sshd -ddd -p2222. Connect on port 2222 with the same credential that you normally do and then after the connection resolves itself that command will terminate.

Persistent Logging

idk if you can edit the /etc/ssh/sshd_config file but if you could then adding the following to it would enable you to get the logs:

LogLevel Debug3

Once you do that you'll need to restart SSH (systemctl restart sshd).

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:

SyslogFacility LOCAL0

You'd then want to modify /etc/rsyslog.conf and add this:

local0.*     /var/log/sshd.log

You'd then need to restart rsyslog (systemctl restart rsyslog)

[esljaz]

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:

• Upgrade the switch to the most recent security patch
• Use setPreferredAlgorithms from my initial post

I'll be closing this off, maybe this helps someone somewhen!