bugzilla-daemon at mindrot.org
2024-Jun-02  12:17 UTC
[Bug 3696] New: ssh client does not respect the "-oMACs" flag
https://bugzilla.mindrot.org/show_bug.cgi?id=3696
            Bug ID: 3696
           Summary: ssh client does not respect the "-oMACs" flag
           Product: Portable OpenSSH
           Version: 9.7p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: root at nixsum.net
According to both sshd config and nmap scan my ssh server accepts the
below cipher suite:
$ nmap -sV --script ssh2-enum-algos 192.168.1.233 -p 22
Starting Nmap 7.93 ( https://nmap.org ) at 2024-06-02 14:57 EEST
Nmap scan report for marciano (192.168.1.233)
Host is up (0.00099s latency).
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.0 (protocol 2.0)
| ssh2-enum-algos: 
|   kex_algorithms: (9)
|       curve25519-sha256
|       curve25519-sha256 at libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       diffie-hellman-group14-sha256
|       diffie-hellman-group16-sha512
|       diffie-hellman-group18-sha512
|   server_host_key_algorithms: (4)
|       rsa-sha2-512
|       rsa-sha2-256
|       ecdsa-sha2-nistp256
|       ssh-ed25519
|   encryption_algorithms: (7)
|       aes256-gcm at openssh.com
|       chacha20-poly1305 at openssh.com
|       aes256-ctr
|       aes256-cbc
|       aes128-gcm at openssh.com
|       aes128-ctr
|       aes128-cbc
|   mac_algorithms: (6)
|       hmac-sha2-256-etm at openssh.com
|       umac-128-etm at openssh.com
|       hmac-sha2-512-etm at openssh.com
|       hmac-sha2-256
|       umac-128 at openssh.com
|       hmac-sha2-512
|   compression_algorithms: (2)
|       none
|_      zlib at openssh.com
Service detection performed. Please report any incorrect results at
https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds
$
The crypto policy enforces the server to start with the proper options
after the "-D" flag
However when I try to test the MACs using the client "-oMACs" flag, it
looks like it accepts MACs it shouldn't:
$ ./ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.9 30 May 2023
$ ./ssh rocky at 192.168.1.233 -oMACs=hmac-sha1
rocky at 192.168.1.233's password: 
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sun Jun  2 15:02:33 2024 from 192.168.1.2
rocky at marciano:~ $ logout
Connection to 192.168.1.233 closed.
$ ./ssh rocky at 192.168.1.233 -oMACs=hmac-md5
rocky at 192.168.1.233's password: 
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Sun Jun  2 15:06:55 2024 from 192.168.1.2
rocky at marciano:~ $ logout
Connection to 192.168.1.233 closed.
What I expect to happen here is a message stating that negotiation
failed, like for example when providing an invalid cipher:
$ ./ssh rocky at 192.168.1.233 -oCiphers=3des-cbc
Unable to negotiate with 192.168.1.233 port 22: no matching cipher
found. Their offer:
aes256-gcm at openssh.com,chacha20-poly1305 at
openssh.com,aes256-ctr,aes256-cbc,aes128-gcm at
openssh.com,aes128-ctr,aes128-cbc
Instead it looks like it falls back to some other MACs to make a
connection.
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Jun-02  12:39 UTC
[Bug 3696] ssh client does not respect the "-oMACs" flag
https://bugzilla.mindrot.org/show_bug.cgi?id=3696
Darren Tucker <dtucker at dtucker.net> changed:
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net
--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(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: chacha20-poly1305 at openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
<implicit> compression: none
$ ssh -v -o MACs=hmac-md5 -oCiphers=aes256-gcm at openssh.com localhost
true 2>&1 | grep MAC
debug1: kex: server->client cipher: aes256-gcm at openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm at openssh.com 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.