openssh bugs - Apr 2022 - [Bug 3415] sftp/ssh doesn't give notice of non-matching MACs but just aborts

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

            Bug ID: 3415
           Summary: sftp/ssh doesn't give notice of non-matching MACs but
                    just aborts
           Product: Portable OpenSSH
           Version: 8.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: calestyo at scientia.org

Hey.

I was trying to connect from:
OpenSSH_8.9p1 Debian-3, OpenSSL 1.1.1n  15 Mar 2022

to the SFTP server from:
  https://www--s0-v1.becke.ch/app/becke-ch--sftp-server--s0-v1/
respectively:
 
https://play.google.com/store/apps/details?id=ch.becke.sftp_server__s0_v1


In my /etc/ssh/ssh_config I had (amongst others) the following
hardening set:
  MACs
hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,umac-128-etm
at openssh.com

i.e. forbidding all non-ETM MACs.


Connecting with that, just "silently" fails:
$ sftp -vvv 192.168.0.150
OpenSSH_8.9p1 Debian-3, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /home/calestyo/.ssh/config
debug3: kex names ok: [diffie-hellman-group14-sha1]
debug3: kex names ok: [diffie-hellman-group-exchange-sha256]
debug1: /home/calestyo/.ssh/config line 220: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 6: Applying options for *
debug3: kex names ok:
[curve25519-sha256,curve25519-sha256 at
libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512]
debug3: gss kex names ok:
[gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group16-sha512-]
debug2: resolve_canonicalize: hostname 192.168.0.150 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/calestyo/.ssh/known_hosts'
debug1: Control socket
"/home/calestyo/.ssh/mux/heisenberg_calestyo at 192.168.0.150:22" does
not
exist
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.0.150 [192.168.0.150] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: connect to address 192.168.0.150 port 22: Connection refused
ssh: connect to host 192.168.0.150 port 22: Connection refused
Connection closed.  
Connection closed


I.e. there is no message as e.g.:
Unable to negotiate with UNKNOWN port 65535: no matching MAC found.
Their offer: hmac-sha1,hmac-ripemd160

Any ideas why not?

Thanks,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

--- Comment #1 from Christoph Anton Mitterer <calestyo at scientia.org>
---
Forgot:
Setting per host
        MACs    +hmac-sha2-512
makes it work.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Christoph Anton Mitterer from comment #0)
[...]
> debug3: gss kex names ok:
> [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group16-sha512-]
This indicates it's a vendor-modified version of OpenSSH.  Can you
reproduce the problem with the stock version from openssh.com?

[...]
> debug1: Connecting to 192.168.0.150 [192.168.0.150] port 22.
> debug3: set_sock_tos: set socket 3 IP_TOS 0x10
> debug1: connect to address 192.168.0.150 port 22: Connection refused
This looks like the server is just not listening on that port.  The
screenshots on the website for the server makes it look like it listens
on port 6789, and as an unprivileged app it probably doesn't have
permission to bind to port 22 anyway.
> I.e. there is no message as e.g.:
> Unable to negotiate with UNKNOWN port 65535: no matching MAC found.
> Their offer: hmac-sha1,hmac-ripemd160
That example looks like it's using a proxycommand.
> Any ideas why not?
I suspect that there's something else going on in your config.  Can you
attach sample config that demonstrates the problem?  (Test it with ssh
-F, but you'll also need to remove any variables in your system-wide
config).

-- 
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.

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

--- Comment #3 from Christoph Anton Mitterer <calestyo at scientia.org>
---
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. In fact I do get that
warning when connection to another (yet very old - and thus not
supporting new MACs) OpenSSH at the university.


As for my debug output... I think I just copy&pasted the wrong one from
the terminal, sorry.
Here's the correct one:
$ sftp -vvv -P 6789 192.168.0.150
OpenSSH_8.9p1 Debian-3, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /home/calestyo/.ssh/config
debug1: /home/calestyo/.ssh/config line 226: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 6: Applying options for *
debug3: kex names ok:
[curve25519-sha256,curve25519-sha256 at
libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512]
debug3: gss kex names ok:
[gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group16-sha512-]
debug2: resolve_canonicalize: hostname 192.168.0.150 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/calestyo/.ssh/known_hosts'
debug1: Control socket
"/home/calestyo/.ssh/mux/heisenberg_calestyo at 192.168.0.150:6789"
does
not exist
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.0.150 [192.168.0.150] port 6789.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/calestyo/.ssh/id_ed25519 type 3
debug1: identity file /home/calestyo/.ssh/id_ed25519-cert type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/calestyo/.ssh/id_rsa type -1
debug1: identity file /home/calestyo/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Debian-3
debug1: Remote protocol version 2.0, remote software version
becke-ch--ssh--s0-0-v1-0
debug1: compat_banner: no match: becke-ch--ssh--s0-0-v1-0
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.0.150:6789 as 'calestyo'
debug3: rekey after 0 bytes, 3600 seconds
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 192.168.0.150 port 6789
Connection closed.  
Connection closed

> That example looks like it's using a proxycommand.
Yes it does... that's the very old OpenSSH mentioned above. We cannot
really upgrade that (at least not soon)... so it's not publicly in the
network and only reachable via some ProxyJump (over a recent
enough/secure node).


I tried with -F none:

$ sftp -vvv -P 6789 -F none -o GSSAPIKeyExchange=no -o
MACs=hmac-sha2-256-etm at openssh.com 192.168.0.150
OpenSSH_8.9p1 Debian-3, OpenSSL 1.1.1n  15 Mar 2022
debug2: resolve_canonicalize: hostname 192.168.0.150 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/calestyo/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/calestyo/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.0.150 [192.168.0.150] port 6789.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/calestyo/.ssh/id_rsa type -1
debug1: identity file /home/calestyo/.ssh/id_rsa-cert type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/calestyo/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/calestyo/.ssh/id_ed25519 type 3
debug1: identity file /home/calestyo/.ssh/id_ed25519-cert type -1
debug1: identity file /home/calestyo/.ssh/id_ed25519_sk type -1
debug1: identity file /home/calestyo/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/calestyo/.ssh/id_xmss type -1
debug1: identity file /home/calestyo/.ssh/id_xmss-cert type -1
debug1: identity file /home/calestyo/.ssh/id_dsa type -1
debug1: identity file /home/calestyo/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Debian-3
debug1: Remote protocol version 2.0, remote software version
becke-ch--ssh--s0-0-v1-0
debug1: compat_banner: no match: becke-ch--ssh--s0-0-v1-0
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.0.150:6789 as 'calestyo'
debug3: put_host_port: [192.168.0.150]:6789
debug3: record_hostkey: found key type ECDSA in file
/home/calestyo/.ssh/known_hosts:31
debug3: load_hostkeys_file: loaded 1 keys from [192.168.0.150]:6789
debug1: load_hostkeys: fopen /home/calestyo/.ssh/known_hosts2: No such
file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
directory
debug3: order_hostkeyalgs: prefer hostkeyalgs:
ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 192.168.0.150 port 6789
Connection closed.  
Connection closed



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.


Thanks,
Chris.

-- 
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.

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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #5 from Damien Miller <djm at mindrot.org>
---
> debug1: SSH2_MSG_KEXINIT sent
> Connection closed by 192.168.0.150 port 6789
> Connection closed.  
> Connection closed
This looks like the remote SSH server waited for the client's KEXINIT,
didn't like what it had to say and closed the connection without
returning any sort of error.

There isn't much that the client can do about a server that behaves
like this.

-- 
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.

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

--- Comment #6 from Christoph Anton Mitterer <calestyo at scientia.org>
---
I'll forward that to the app upstream... and then I guess we can close
this here?!

-- 
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.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #7 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Christoph Anton Mitterer from comment #6)
> I'll forward that to the app upstream... and then I guess we can
> close this here?!
Yes I think so, there's nothing much the OpenSSH client could do
different in this case.

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
Closing bugs from OpenSSH 9.1 release cycle

-- 
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.