Client timeout after sending client version string after upgrading from 1.3.7e to 1.3.8b, but not reproducible for me about proftpd

[cfiehe]

Hi @maltris,
we faced the same issue and were confronted with hanging clients (2 or 3 out ouf 150) at the same point during SSH handshake. We found out that the server-side worked properly and sent a correct response, but the client did not receive it (using tcpdump). The problem was, that this happened on the customer's side and we had only limited debugging capabilities. The client's host was based on Ubuntu 20.04. We never understood the issue completely and have not find a way to reproduce it, but adding

SFTPOptions PessimisticKexinit

helped to workaround the issue of hanging clients. Maybe, you can give it a try, too.

On the client’s side there was a firewall appliance in place and we had it in suspicion of dropping the server's response. Unfortunately, we could not get the firewall logs to underline that theory. For test purposes, we used a pretty old ProFTPD server that was based on 1.3.5e and used the setting for optimistic key exchange. That was working without any issues and the SSH handshake completed normally. Maybe the issue was introduced, starting with ProFTPD 1.3.8.

[Castaglia]

Hmm. I've not heard of any reports along these lines before. Let's see if we can get some more details.

Would it be possible to add the following to your ProFTP configuration?

TraceLog /var/log/proftpd-trace.log
Trace ssh2:30 sftp:30

Note that this will generate quite a lot of logging data, for the working connections. I am most interested in the additional trace logging seen for the non-working sessions.

In the mean time, I am attempting to reproduce this issue locally, using debian:12 and alpine:3.19.0 Docker containers; so far, all of the connection attempts are working as expected for me as well.