openssh bugs - Jan 2025 - [Bug 3780] New: connecting using KexAlgorithms list fails without spaces

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

            Bug ID: 3780
           Summary: connecting using KexAlgorithms list fails without
                    spaces
           Product: Portable OpenSSH
           Version: 9.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: sven.ginka at gmail.com

I have issues connecting to my ssh server:

using the predefined default kex list:

debug2: KEX algorithms:
curve25519-sha256,curve25519-sha256 at
libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,
...

So I tried to provide a manual list for kex algorithms, because it
looks like that specific algorithms doesnt work. on that way I figured
out the following issue: 


ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp256  ... ok

ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp384  ... ok


ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp256,ecdh-sha2-nistp384
... fails

ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp384,ecdh-sha2-nistp256
  ... fails


ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp384,
ecdh-sha2-nistp256   ... ok

ssh -vv myServer -o KexAlgorithms=ecdh-sha2-nistp256,
ecdh-sha2-nistp384   ... ok


it smells like, it has something to do with the spaces?

as the list provided doesnt have spaces, I wondering how to provide a
correct list?

this is really curious.

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Please attach a debug trace from a failing connection

-- 
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=3780

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
Also is this a vendor supplied or otherwise modified version?  A quick
test with the stock code does not show a problem.

-- 
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=3780

--- Comment #3 from SG <sven.ginka at gmail.com> ---
Created attachment 3854
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3854&action=edit
ssh failed log

-- 
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=3780

--- Comment #4 from SG <sven.ginka at gmail.com> ---
additional notes:

- all ssh config is default (except root disabled, pass auth disabled)
- it looks like supplying more than one kex algorithm always stops,
waiting for the reply of the remote end (see ssh_failed_log).
- the connection is via a wireguard tunnel
- always using the same setup working fine for months on 40+ machines
and it occured recently (maybe after some apt update) only on a subset
of about 10 machines


client:

$ apt show openssh-client
Package: openssh-client
Version: 1:8.2p1-4ubuntu0.11
Priority: standard
Section: net
Source: openssh
Origin: Ubuntu

$ uname -a
Linux client 5.15.0-1062-aws #68~20.04.1-Ubuntu SMP Wed May 1 15:24:09
UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

server:

$ apt show openssh-server 
Package: openssh-server
Version: 1:8.4p1-5+deb11u3+b1
Priority: optional
Section: net
Source: openssh (1:8.4p1-5+deb11u3)

$ uname -a
Linux myserver 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST
2023 aarch64 GNU/Linux

-- 
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=3780

--- Comment #5 from SG <sven.ginka at gmail.com> ---
Created attachment 3855
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3855&action=edit
ssh failed log - provide 2x kex algorithms (also fails)

-- 
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=3780

--- Comment #6 from SG <sven.ginka at gmail.com> ---
Created attachment 3856
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3856&action=edit
ssh success log - provide 1x kex algorithms - works like charm

-- 
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=3780

--- Comment #7 from Darren Tucker <dtucker at dtucker.net>
---
> - it looks like supplying more than one kex algorithm always stops, waiting
for the reply of the remote end (see ssh_failed_log).
> - the connection is via a wireguard tunnel
That combination sounds like a Path MTU problem.  One end (the client
in this case) sends a packet larger than an MTU somewhere on the
network path, the packet gets fragmented, (eg a firewall) drops the 2nd
and subsequent fragments (because they don't have port information),
and the first fragment times out waiting for reassembly on the other
end.  TCP retransmits the data, which is fragmented exactly the same
way.

In the case of SSH, the packet sizes are influenced by the algorithm
lists, so adding the 2nd hostkey algo might be pushing the packet over
the fragmentation limit.  If this is what's happening, you will see the
bytes stuck in the "SendQ" column of "nestat" for the TCP
connection on
one of the ends.  The number will be non-zero and never decreasing,
indicating that TCP never acks the data.

-- 
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=3780

--- Comment #8 from SG <sven.ginka at gmail.com> ---
wow. I couldnt be impressed more!

its exactly as you say. it has nothing to do with ssh. problem solved.

-- 
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=3780

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #9 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to SG from comment #8)
> wow. I couldnt be impressed more!
> 
> its exactly as you say. it has nothing to do with ssh. problem
> solved.
You're welcome.  We've seen this a few times before (eg
https://bugzilla.mindrot.org/buglist.cgi?bug_status=__all__&content=%22Path%20MTU%22
plus probably at least a half dozen times on the mailing lists over the
years).

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