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@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@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@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: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.
Forgot: Setting per host MACs +hmac-sha2-512 makes it work.
(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).
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.
(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.
> 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.
I'll forward that to the app upstream... and then I guess we can close this here?!
(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.
Closing bugs from OpenSSH 9.1 release cycle