SSH connection issues - Unable to get packet length
Over the past few months, I have tried to track down why this was happening, but I thought it was a server-side issue. However, now that I am connecting to more than one server, I see this on all my SSH connections, so I'm starting to look at the client side.
The issue
Open an SSH session and start using it. I can actively interact with the shell or have a script running, but I'll randomly get the error below, killing the session.
Things I have tried.
- Verified server-side timeouts; I am not hitting this as I am actively interacting with the sessions.
- Mac Firewall (as I was creating this topic, I decided to disable it and see what effect that has. If the issues disappear, I would like to find a way to investigate why, as I do not want to leave the firewall disabled)
- Every SSH setting I can think of.
Does anyone have any pointers on what setting I should review or logs that can give more info about what's happening? I'm about to reach the point where I am going to re-image this machine.
System Info:
macOS: Sequoia 15.0.1
RDM: Version 2024.3.4.4
The error:
[~]# [10/17/2024 11:22:23 AM] Unable to get packet length
[10/17/2024 11:22:23 AM] Bytes sent: 3360, Bytes received: 9172
[10/17/2024 11:22:23 AM] Packets sent: 32, Packets received: 66
[10/17/2024 11:22:23 AM] Kex completed: 1
Thanks,
All Comments (3)
Hello,
Are you using a Bitvise SSH Server ? We are aware of a similar issue with Bitvise SSH Servers.
If not, can you give us more information on the kind of server you are using ?
Best regards,
Maxim Buisson
I am not using Bitvise, I have had this issue with connections to Linux servers of various distributions.
I see. Then it is probably not the same issue.
Please, follow the documentation here: https://docs.devolutions.net/rdm/kb/rdm-windows/how-to-articles/send-ssh-logs-verbose/
to generate a log file. Use your SSH until the problem occurs, then send the log file content to me via direct message on the forums here. Hopefully there will be something in there to help us find the issue.
Best regards,
Maxim Buisson
