Mailing List Archive

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

Darren Tucker <dtucker@dtucker.net> changed:

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

--- Comment #2 from Darren Tucker <dtucker@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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

--- Comment #3 from Christoph Anton Mitterer <calestyo@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@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@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@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@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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

--- Comment #4 from Darren Tucker <dtucker@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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

Damien Miller <djm@mindrot.org> changed:

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

--- Comment #5 from Damien Miller <djm@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

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

--- Comment #6 from Christoph Anton Mitterer <calestyo@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs