This is not an opnsense issue I think, it just happen on to only affect opnsense in my environment.
I get "Bad packet length" or "Connection corrupted" very quickly and my ssh connection drops. This only happens since upgrade to macOS 15.0 sequoia (yes, I shouldn't have, what came over me to upgrade to a .0 release, I don't know...)
"Good" hosts (stable ssh) have different ssh version (OpenSSH_8.2, dropbear...), that's what I can observe so far.
I'm just posting this in here in case anyone is having the same issue, maybe we can cross reference our findings and narrow it down quicker.
Hmmm, I can confirm that Sequoia 15.0 openssh runs fine with opnsense 24.7.4_1 /.5. No issues at all. both from my internal LAN and WLAN.
There is usually only one reason for such an error message - bad encryption or decryption. Aside of ssh implementation bugs (which is usually very unlikely) there is also the possibility of line or HW issue or brute force attacks... here, a detailed log would help ...
br br
ssh -v frequently helps.
I found this in the meantime, reenforcing my suspicions that macOS sequoia has broken something:
https://www.reddit.com/r/SentinelOneXDR/comments/1fj3wia/various_ssl_errors_after_upgrade_from_sonoma_to/
I also had the issue once on a different host (openwrt) now, so it's definitely not an opnsense issue, it just happens a lot on my opensense host somehow.
I ran ssh with -v, but there are no errors are connection setup time. It breaks later, it's random. But it takes less than a minute to happen in general, and all I see is this:
root@opn:/usr/ports/net/cloudflared # Bad packet length 558727141.
ssh_dispatch_run_fatal: Connection to 2a02:1106:15:8402:: port 26533: Connection corrupted
> Bad packet length 558727141.
That's bad indeed. oO
Cheers,
Franco
Does resetting the SSH key help?
ssh-keygen -R <IP-Adresse/Name>
It's confirmed, the problem is macOS, disabling the macOS firewall under Settings > Network > Firewall works around the issue but does introduce another issue – I anticipate turning firewall off might not be met with enthusiasm on this forum somehow ;)
What I noticed is that, with "ssh -v" and firewall off, I regularly see such lines:
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1
which I do not see when firewall is on. Hence, one problem could be that the firewall is blocking the keepalives. But it probably isn't the only thing the firewall is blocking.
Hope this helps anyone struggling to understand why ssh is suddenly broken.
In my case it helped to generate a new SSH key.
There was no need to turn off the firewall.
A major change in macOS Sequoia is that it by default will limit application's access to local network (basically the hosts on the same subnet) for privacy reason [1].
Personally I experienced a similar problem after upgrading doing SSH and the error message is hard to understand. If this is the case, the errno will be -65 (EHOSTUNREACH) but SSH seems to not expose this error code well (the detail is from my node.js application).
You can try grant your terminal emulator Local Network access in your Settings and try again.
[1] https://support.apple.com/en-us/102229
(linked for iOS counterpart that rolled out few years ago since no obvious documentation is up on Apple's website for macOS. The principle is the same.)