[Bug 3415] sftp/ssh doesn't give notice of non-matching MACs but just aborts
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Sat Apr 2 14:48:47 AEDT 2022
https://bugzilla.mindrot.org/show_bug.cgi?id=3415
--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Christoph Anton Mitterer from comment #3)
> Hey Darren.
>
> Uhm... I could try to build a "clean" OpenSSH with all the Debian
> modifications removed - but AFAICS none of those should really touch
> the warning about a failed MAC negotiation.
The gssapi patch for example adds at least new key exchange methods.
There have been problems in the past where implementations have had
problems related to the size of the initial exchanges (probably due to
fixed-sized buffers).
It's hard to debug a system you have not seen and can't interact with,
and it gets harder the more variables you add. Your debug output did
not make sense compared to your problem description and code
modifications would have been one possible reason why.
> As for my debug output... I think I just copy&pasted the wrong one
> from the terminal, sorry.
Ok that explains the debug output.
[...]
> debug3: send packet: type 20
> debug1: SSH2_MSG_KEXINIT sent
> Connection closed by 192.168.0.150 port 6789
> Connection closed.
> Connection closed
This looks like the server is just closing the connection when it gets
the initial protocol banner (or possibly crashing) instead of replying
with the list of algorithms that it does support, which would let the
OpenSSH client figure out that there is no MAC in common. You can
confirm this by tcpdumping the connection (this part of the connection
is prior to encryption being enabled) and comparing that to your case
where you do get the mismatch warning. RFC4253 section 7 describes how
this is supposed to work.
[...]
> So it doesn't seem to be my ssh config... nevertheless if you'd
> still need it, tell me and I'd send it to you privately it's not
> really that secret... nevertheless... shouldn't probably made too
> public as it contains some network information and so on.
I don't think we need it now. The reason I asked was that the debug
output did not match the symptoms and entries in the config was one
possible reason why.
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list