On 24.04.24 19:59, Guilhem Moulin wrote:
Control: reassign -1 dropbear-bin 2022.83-1+deb12u1
Control: retitle -1: The 'no-agent-forwarding' key restriction disables server
alive message support
Control: tag -1 upstream
On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote:
On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote:
It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3
-o ServerAliveInterval=1 root@yourdropbearserver`. The client should then
disconnect after 3 seconds.
Seems to work as expected for me:
$ ssh -oLogLevel=DEBUG3 \
-oServerAliveCountMax=3 -oServerAliveInterval=1 \
-oUserKnownHostsFile=/tmp/known_hosts \
-i /tmp/test.key \
-l user -p 10022 127.0.0.1 sleep 300
[…]
No wait, this works in the main system but indeed at initramfs stage the
client doesn't get responses to its alive probes.
The above was misleading, turns out this was not due to the initramfs
per se, but because its authorized_keys file had the following
restrictions (which were set in my test environment per cryptsetup-initramfs'
recommendations):
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock"
Lee, I assume you have the ‘no-port-forwarding’ restriction too? It
appears to disable server alive message support for some reason. This
is reproducible at initramfs stage as well as in the main system.
my /etc/dropbear/initramfs/dropbear.conf has:
DROPBEAR_OPTIONS="-s -j -k -I 180 -c /usr/bin/cryptroot-unlock"
-j and -k are "disable local/remote port forwarding".
Seems like we cracked the case. Nice! Is there a chance we can get that into
bookworm via s-p-u?
