https://bugzilla.mindrot.org/show_bug.cgi?id=3696

Darren Tucker <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #1 from Darren Tucker <[email protected]> ---
(In reply to Nikola from comment #0)
[...]
> Instead it looks like it falls back to some other MACs to make a
> connection.

Probably not, or at least not in the way you expect.  These days the
default cipher chacha20-poly1305 and a few other high priority ciphers
(such as AES GCM which is probably relavnt for your case) are
authenticated ciphers and have their own implicit MAC).  If such cipher
are selected there is no separate MAC to be selected.

$ ssh -v -o MACs=hmac-md5 localhost true 2>&1 | grep MAC
debug1: kex: server->client cipher: [email protected] MAC:
<implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC:
<implicit> compression: none

$ ssh -v -o MACs=hmac-md5 [email protected] localhost
true 2>&1 | grep MAC
debug1: kex: server->client cipher: [email protected] MAC:
<implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC:
<implicit> compression: none

Try: ssh -oCiphers=aes256-ctr -oMACs=hmac-sha1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

Reply via email to