Thanks for the report.
This was a regression in the re-exec changes, I've pushed a fix to
https://github.com/mkj/dropbear/commit/544f28a05165eb97e18cc03fc8990da842ec3a94
The childpipe file descriptor is used to notify the parent listener that
auth has completed, but I'd missed that the inetd path (used for
re-exec) ignores that.
Cheers,
Matt
On 2022-06-08 6:28 am, Matthias Lang wrote:
Hi,
My colleague Thomas noticed some unexpected behaviour in recent
dropbear versions. It unexpectedly limits concurrent logins, apparently
to MAX_UNAUTH_CLIENTS.
I expected that setting to limit how many pre-authorisation clients
can connect, but have no effect on the number of authorised
clients. That's how versions dropbear prior to c7b7c9a99 behave.
I checked the mailing list archives back to January. Nothing.
Steps to reproduce on a normal x86 debian box below.
Matt
--
0. Perfectly normal x86 linux box, not some weird embedded system
uname -a
Linux hec 5.17.0-1-amd64 #1 SMP PREEMPT Debian 5.17.3-1
(2022-04-18) x86_64 GNU/Linux
1. Build c7b7c9a99 with this in localoptions.h:
#define MAX_UNAUTH_CLIENTS 2
make clean && ./configure && make
2. Set up key file and start SSH server
./dropbearkey -t rsa -f rsa_host_key
sudo ./dropbear -E -p 8000 -F -r ./rsa_host_key
3. Test having three parallel SSH sessions open:
ssh -p 8000 127.0.0.1// in one xterm. works.
ssh -p 8000 127.0.0.1// in a second xterm. also works.
ssh -p 8000 127.0.0.1// fails
kex_exchange_identification: Connection closed by remote host
4. Rebuild with ebb4018889
make clean && ./configure && make
Retry step 3. Now it works fine.
(5. Rebuild c7b7c9a99 with #define DROPBEAR_REEXEC 0. Also works fine.
So
it looks like REEXEC is doing something something different with either
file descriptors or a count of the connections.)
--
--eot--