Dropbear's decompression could erroneously exit with
"bad packet, oversized decompressed"
for a valid 32768 byte decompressed payload (an off-by-one error).
It could be triggered particularly with larger SSH window sizes.
This change also simplifies the function by allocating a
single 32kB buffer rather than incrementally increasing the size.
This was the default prior to 2022.82 and makes a significant
difference to performance. Perhaps at a later time
this could be made more configurable.
Discussion in https://github.com/mkj/dropbear/issues/174
Since re-exec change in 2022.82 Dropbear count
treat authenticated sessions towards the unauthenticated
session limit. This is fixed by passing the childpipe FD
through to the re-execed process.
Following issue "Compilation error when disabling pubkey authentication (DROPBEAR_SVR_PUBKEY_AUTH)" from davidbernard04, code is modified to take in account that requesting information from method "ses.authstate.pubkey_info" isn't possible since the method is disabled when DROPBEAR_SVR_PUBKEY_OPTIONS_BUILT value is 0.
When multihop executes dbclient it should only add -i arguments
from the original commandline, not the default id_dropbear key.
Otherwise multiple -i arguments keep getting added which
results in servers disconnecting with too many auth attempts
When dropbear is used in a very restricted environment (such as in a
initrd), the default user shell is often also very restricted
and doesn't take care of setting the PATH so the user ends up
with the PATH set by dropbear. Unfortunately, dropbear always
sets "/usr/bin:/bin" as default PATH even for the root user
which should have /usr/sbin and /sbin too.
For a concrete instance of this problem, see the "Remote Unlocking"
section in this tutorial: https://paxswill.com/blog/2013/11/04/encrypted-raspberry-pi/
It speaks of a bug in the initramfs script because it's written "blkid"
instead of "/sbin/blkid"... this is just because the scripts from the
initramfs do not expect to have a PATH without the sbin directories and
because dropbear is not setting the PATH appropriately for the root user.
I'm thus suggesting to use the attached patch to fix this misbehaviour (I
did not test it, but it's easy enough). It might seem anecdotic but
multiple Kali users have been bitten by this.
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903403
For the time being Dropbear will only allow SK auth with default
parameters, user-presence needs to be set.
In future handling of authorized_keys option "no-touch-required" can be
added.
This code would also be refactored to share between ecdsa and ed25519
once I get hardware/emulation to test ed25519.
