SSH framing problem? Bad packet length 1397966893

[Darren Tucker]

On 9 October 2018 at 04:58, Mirko Raner <mirko at raner.ws> wrote:
> I am trying to troubleshoot an SSH connectivity problem (client v6.6.1p1,
> server v6.7p1) that also involves a custom packet forwarding service (so,
> it may not actually be an SSH problem).
>
> The issue is intermittent, and, when present, manifests itself with the
> client error message "Bad packet length 1397966893. Disconnecting: Packet
> corrupt." Based on my limited understanding of the SSH Transport Layer
> Protocol, I gathered that this essentially signifies that the first four
> bytes of the initial protocol identification packet ("SSH-") are being
> misinterpreted as the packet length header (per RFC 4253 section 6).

That seems like a plausible explanation.

$ perl -le 'print pack("N1", "1397966893")'
SSH-

> My main question is: does the SSH Transport Layer Protocol expect the
> various messages always to be sent as individual packets, or does it
> support stream-based connections where messages can be reframed into more
> or fewer packets?

SSH assumes only an 8 bit clean bidirectional byte stream and should
not be affected as long as the byte stream remains intact and in the
correct order.  Quoting RFC4253:

   SSH works over any 8-bit clean, binary-transparent transport.  The
   underlying transport SHOULD protect against transmission errors, as
   such errors cause the SSH connection to terminate.

I'd guess your packet forwarding thing is either delivering the
initial packet containing the SSH banner twice or mixing up two
different streams.  I don't think it's delivering the stream out of
order because that would not get past the initial exchange. I'd look
for duplicate packets first because that seems like the most plausible
one to me.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.