Currently, I use Zerotier to combine SSH on Debian 12 successfully and reliability. The server is encrypted FDE cryptsetup/LUKS2 and requires a password after each restart. I would like to use dropbear-initramfs for remotely introducing the password, but I also need that Zerotier also starts in initramfs (before Dropbear), because the home server does not have a public IP. How to add Zerotier to Initramfs?

How to generate SSHFP records for a Dropbear instance at OpenWrt? I have **dropbearconvert** and **openssh-keygen** installed, but nothing works. Always invalid format or similar errors. There are two host key files available: /etc/dropbear/dropbear_dss_host_key /etc/dropbear/dropbear_rsa_host_key Any ideas how to get a SSHFP record?

I have an OpenWrt router, I want to disable password authentication on SSH, so that one can only authenticate with keys. This is easily achieved by following the guide in the documentation, however, I want to only disable password authentication on the WAN interface, is this possible?

I have a running **dropbear-initramfs** server in my **nitramfs** environment, however I am not able to get it to display banner. Following contents of /etc/dropbear/initramfs/dropbear.conf work just fine:

...
DROPBEAR_OPTIONS="-I 60 -p 22 -j -k -s -c cryptroot-unlock"
...

Specifying banner-file, however, results in dropbear failing to start, even though /etc/banner & /etc/dropbear/initramfs/banner files are present and populated (I have even tried turning on **+x** bit)

...
DROPBEAR_OPTIONS="-I 60 -p 22 -j -k -s -b /etc/banner -c cryptroot-unlock"
...

Updating the initramfs with update-initramfs -u and checking lsinitramfs /initrd.img | grep banner shows no banner file present. Rebooting results in dropbear not starting and port remains closed. I already verified that this singular change is responsible for dropbear (not) starting. I am running **Debian 12** with **dropbear-initramfs/stable,now 2022.83-1+deb12u2**. On my previous Arch installation, simply including -b /etc/banner in the **DROPBEAR_OPTIONS** was sufficient to populate initrd with banner file. Is there something I am missing?

I'm trying to get fail2ban working on a DietPi but no matter what I do it won't ban me. I've found quite a few threads about this but just can not get it working, so apologies for any repetition. Thanks for any help fail2ban status **My jail.local:**

[DEFAULT]
enabled = true
ignoreip = 127.0.0.1/8
ignorecommand =
backend = systemd
mode = normal
filter = %(__name__)s[mode=%(mode)s]
findtime = 600
maxretry = 3
bantime = 600
banaction = iptables-multiport

[dropbear]
enabled = true
filter = dropbear

[sshd]
enabled = true
filter = sshd

**filter.d/dropbear.conf contains:**

prefregex = ^%(__prefix_line)s(?:[Ll]ogin|[Bb]ad|[Ee]xit).+$
failregex = ^[Ll]ogin attempt for nonexistent user ('.*' )?from :\d+$
            ^[Bb]ad (PAM )?password attempt for .+ from (:\d+)?$
            ^[Ee]xit before auth \(user '.+', \d+ fails\): Max auth tries reached - user '.+' from :\d+\s*$
ignoreregex =

**Logs below:** *sudo journalctl -u dropbear -n 10*

...
Nov 01 13:01:44 DietPi dropbear:  Nov 01 13:01:44 Child connection from IPADDRESS:52290
Nov 01 13:01:44 DietPi dropbear:  Nov 01 13:01:44 Failed loading /etc/dropbear/dropbear_dss_host_key
Nov 01 13:01:46 DietPi dropbear:  Nov 01 13:01:46 Bad password attempt for 'NAME' from IPADDRESS:52290
Nov 01 13:01:47 DietPi dropbear:  Nov 01 13:01:47 Bad password attempt for 'NAME' from IPADDRESS:52290
Nov 01 13:01:48 DietPi dropbear:  Nov 01 13:01:48 Bad password attempt for 'NAME' from IPADDRESS:52290
Nov 01 13:01:48 DietPi dropbear:  Nov 01 13:01:48 Exit before auth from : (user 'NAME', 3 fails): Exited normally
...

*sudo fail2ban-client status dropbear*

Status for the jail: dropbear
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- Journal matches:
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

I have configured [DropBear SSH](https://matt.ucc.asn.au/dropbear/dropbear.html) in a Linux (Ubuntu 22.04) machine. The configuration I'm using is the following:

$ cat /etc/dropbear-initramfs/config 
#
# Configuration options for the dropbear-initramfs boot scripts.
# You must run update-initramfs(8) to effect changes to this file (like
# for other files under the '/etc/dropbear-initramfs' directory).

#
# Command line options to pass to dropbear(8)
#
# -I 0: disables idle timeouts for innactivity
# -s: disable passwords
DROPBEAR_OPTIONS="-p 2222 -I 0 -s"

#
# On local (non-NFS) mounts, interfaces matching this pattern are
# brought down before exiting the ramdisk to avoid dirty network
# configuration in the normal kernel.
# The special value 'none' keeps all interfaces up and preserves routing
# tables and addresses.
#
#IFDOWN=*

And I have tested it powering down (manually) the machine; the server starts immediately after startup and I'm able to connect to it. However, if I run sudo reboot from the machine itself, the server does not start after rebooting and I can't connect to the SSH server of DropBear (logs in the machine show that DropBear is running but the machine is not reachable in 2222). The only sequence that seems to work (**almost** every time) is if I restart the machine doing:

$ sudo -i
# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger

I'm not entirely sure why but I guess the signals sent to reboot the machine are different between the two aforementioned methods. Can this be the issue? What's the best way to reboot a machine and have DropBear running after rebooting?

I am trying to convert an OpenSSH-generated private host key to the PEM format, so that I can use it also in dropbear-initramfs. However, when trying to do so using the ssh-keygen program, I am getting an error as follows: …# ssh-keygen -m PEM -e -f /etc/ssh/ssh_host_ed25519_key >/root/ssh_host_ed25519_key do_convert_to_pem: unsupported key type ED25519 How can I perform this operation?

I am trying to decrypt a fully encrypted system using LUKS over SSH. I followed [stinky parkia's guide to unlocking device over ssh](https://stinkyparkia.wordpress.com/2014/10/14/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu-server-14-04-1-with-static-ipst/) . However, the password is not working. I am able to reach the prompt to enter the passphrase but it's simply not accepting the correct password. Error: cryptsetup: cryptsetup failed, bad password or options?, I type the same password with a keyboard attached directed with the Pi4 and it works. I little more research showed initramfs option is required in crypttab. Updated crypttab:

# 				
sdcard	/dev/mmcblk0p2	none	luks,initramfs

However, the password is still not working over SSH. Any hints on what I am possibly doing wrong? Details: 1. uname -a: Linux raspi 6.1.21-v8+ #1642 SMP PREEMPT aarch64 2. OS: Raspberry OS lite 3. cryptsetup --version: cryptsetup 2.3.7 --- Update #1: Found similar instructions on a [linuxconfig.org blog](https://linuxconfig.org/introduction-to-crypttab-with-examples) , same problem. Update #2: I thought the keyboard layout is different, but I typed the password in plain text and all characters are as expected.

I've setup the Debian package dropbear-initramfs to unlock my homeservers disk over SSH. Unfortunately, the router assigns a different IP to the server on every boot and its DNS does not know the server by its hostname at initramfs stage. Once I unlocked the disk and the server completed boot, I can resolve its hostname.

I am trying to boot into RescueInitRamfs (https://wiki.debian.org/RescueInitramfs) on my Debian server after configuring DropBear as per https://benediktkr.github.io/ops/2015/05/01/remote-fde.html (mostly). I have tried updating the kernel boot parameter in file /etc/default/grub by setting GRUB_CMDLINE_LINUX_DEFAULT="quiet rescue/enable=true" and GRUB_CMDLINE_LINUX="rescue/enable=true" (as per https://www.debian.org/releases/stable/amd64/ch08s06.en.html) , then running sudo update-grub. I have verified that the kernel is being booted with this parameter by inspecting /proc/cmdline. It seems that this kernel parameter has no effect and the system is booting straight into "normal" (not rescue) mode. I then tried to boot into rescue mode by setting the kernel parameter systemd.unit=rescue.target and now I am unable to SSH in but the server seems to be online as I can ping it. 1) Why is rescue/enable=true doing nothing? 2) What is the difference between rescue/enable=true and systemd.unit=rescue.target? 3) What should I be doing to get this working with DropBear? UPDATE - to clarify, I only have SSH access. No console.

I don't know why, but I can't manage to follow these instructions on my debian stable. After installing dropbear and busybox, I tried to run initramfs -u. I got here a strange warning: # update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.9.0-4-amd64 dropbear: WARNING: Invalid authorized_keys file, remote unlocking of cryptroot via SSH won't work! Then, I tried to look in the file /etc/initramfs-tools/root/.ssh/id_rsa, but there is no folder root in the initramfs folder. I also tried to run dropbearkey -t dss -f /etc/initramfs-tools/etc/dropbear/dropbear_dss_host_key but there is no folder /etc/initramfs-tools/etc/, so this command also fails. Of course, I can create these folders, but I'm afraid that this strange behaviour does not come from a deeper error. If it can help, here is the content of the initramfs folder: me@server:/etc/initramfs-tools# ls conf.d hooks initramfs.conf modules scripts update-initramfs.conf Thank you!

I've installed dropbear to be able to remotely decrypt my LUKS partition. It worked flawlessly after executing update-initramfs -u, however one restart later the dropbear daemon didn't seem to start as the SSH connection times out. After decrypting (non-remotely), executing update-initramfs -u and rebooting again it works flawlessly. My server runs Debian 11 and Dropbear v2020.81 Any ideas why this is?

Currently, I am running into an issue with dropbear. I have set the maximum number of concurrent ssh sessions to 10 but I still able to ssh an 11th sessions. Would you please let me know what I am doing wrong? cat /proc/sys/kernel/pty/max 10 I am using a 64bit platform.

I'm trying to gain ssh access to my router. Currently I only have telnet access and I installed dropbear and is running (using opkg on a usb drive connected to the router). From the beginning, what I did was generate a private key and decrypt it (since dropbear doesn't support this yet) and the public one: cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys I uploaded the public key (authorized_keys) to /root/.ssh. I put the file on a Apache server (in my local computer) and download it on the router using wget (so the downloaded file gets root as owner/group) and then changed the permissions to 0600 (same for the client but with my user). When I try to access, it gives me a "Permission denied (publickey)" error: $ ssh -v -i ~/.ssh/id_rsa root@192.168.1.1 OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version 2.0, remote software version dropbear debug1: no match: dropbear debug1: Authenticating to 192.168.1.1:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o debug1: Host '192.168.1.1' is known and matches the RSA host key. debug1: Found key in /home/chazy/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/chazy/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey). Unless I'm misreading what the documentation (GitHub repo ) says: > Server public key auth: > > You can use ~/.ssh/authorized_keys in the same way as with OpenSSH, > just put the key entries in that file. They should be of the form: > > ssh-rsa > AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV+ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk/yU99UVv6NWV/5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET/MG8qyskG/2IE2DPNIaJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= > someone@hostname > > You must make sure that ~/.ssh, and the key file, are only writable by > the user. Beware of editors that split the key into multiple lines. > > Dropbear supports some options for authorized_keys entries, see the > manpage. I did everything it says, so I don't know where the problem could be. The documentation mentions another way: > Client public key auth: > > Dropbear can do public key auth as a client, but you will have to > convert OpenSSH style keys to Dropbear format, or use dropbearkey to > create them. > > If you have an OpenSSH-style private key ~/.ssh/id_rsa, you need to > do: > > dropbearconvert openssh dropbear ~/.ssh/id_rsa ~/.ssh/id_rsa.db > dbclient -i ~/.ssh/id_rsa.db > > Dropbear does not support encrypted hostkeys though can connect to > ssh-agent. So this menas that if I convert the private key to a dropbear private key, I can use the dropbear client to connect to the dropbear server: dropbearconvert openssh dropbear id_rsa id_rsa.db I'm going to give this a try and see if it works. But anyways, Server public key auth should work.

I use an alias for ssh alias ssh alias ssh='ssh -t -K -Y I want to use ssh forwarding X11 except for one host so i did this: vim .ssh/config host myhost port 22 ForwardX11 no HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa but.. ssh myhost sh: xauth: command not found myuser@myhost$ seems my option is ignored..why? I also tried ForwardX11 no ForwardX11trusted no but no success. A workaround can be this... \ssh myhost so -t -K -y is ignored, but I prefer a more clean solution I forgot: the remote server use dropbear reading this page i see is possible to disable X11 for a specific key on server vim .ssh/authorized_keys no-X11-forwarding ssh-rsa...... but in this case it refuse also \ssh command! ssh myhost X11 forwarding request failed on channel 0 Connection to myhost closed by remote host. Connection to myhost closed. \ssh myhost Connection to myhost closed by remote host. Connection to myhost closed. Using this line on server works..but no for pubkey, it require the password no-agent -forwarding, no-port-forwarding, no-x11-forwarding ssh-rsa....

I built a linux kernel (v. 5.17.1) with default config and created a minimal root fs using buildroot (both for x86_64). I modified the configuration of buildroot to use glibc and added DHCP for eth0. Furthermore I added a dropbear ssh server. I can boot into the system using qemu:

qemu-system-x86_64 -m 1G -kernel linux-5.17.1/arch/x86_64/boot/bzImage -initrd buildroot-2022.02/output/images/rootfs.cpio -net nic -net user,hostfwd=tcp::2222-:22

The logs state that dropbear (sshd) is started successfully, however the server is not running when trying to connect. I can start it manually using /etc/init.d/S50dropbear start, which also states that it was successful. But it seems to quit right after it started. If I run dropbear in the *do-not-fork* mode in the foreground, everything is working fine, i. e:

dropbear -FBR

Does anyone have an idea why this could be the case?

I've been trying to open a LUKS container via SSH using dropbear and initramfs/initrd image. My setup works well. I mean, I log via SSH to the target machine, then I see the prompt saying Please unlock disk rpi_crypt: , and then I enter the right password and the LUKS container is being opened and the system boots. But when I typed the password via SSH, after a few secs I got the following error: $ ssh 192.168.1.239 Please unlock disk rpi_crypt: Error: Timeout reached while waiting for PID 212. Connection to 192.168.1.239 closed. So where does this error come from and how to fix it?

I'm having issues unlocking an encrypted disk over ssh using dropbear. I've followed this guide to set it up, but I just end up getting Permission denied (publickey) error I copied the public key from my machine ~/.ssh/id_rsa.pub to the server /etc/dropbear-initramfs/authorized_keys and updated with update-initramfs -u -k all The config of /etc/dropbear-initramfs/config currently have this content: DROPBEAR_OPTIONS="-I 120 -c /bin/cryptroot-unlock" I also tested with the config from the article DROPBEAR_OPTIONS="-RFEsjk -c /bin/cryptroot-unlock" --- Using SSH, I've tried specifying the identity key (-i), tried with no username, server machine username, my machine username etc... I simply cannot get past the Permission denied error.

When I connect to my Dropbear SSH server for the first time, I get the following message:

me@laptop:~$ ssh me@server
The authenticity of host 'server' can't be established.
RSA key fingerprint is SHA256:NycCxoRiiSAGA7Rvlnuf1gU8pazIpXJKZ3ukdivyam8.
Are you sure you want to continue connecting (yes/no)?

To make sure that this is the correct server, I want to compare the stated fingerprint from that message to the server's real fingerprint. How can I find out the server's RSA host key fingerprint?

I'd like to use [dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) as an alternative, minimal ssh-server and -client. dropbear allows the use of private-public-keys for ssh-access, although [the keys are not identical to the ones used by openssh and have to be converted using the dropbearconvert-command](https://github.com/mkj/dropbear) (which is easy to do). The issue I'm having is that [dropbear doesn't natively support encrypted private keys](https://github.com/mkj/dropbear) . But leaving unencrypted ssh-keys on my laptop is something I'd like to avoid out of principle. Therefore my question: does anyone have any good ideas on how to circumvent that issue and have a method (script?) that: * decrypts the keys I use for dropbear (e.g. using gnupg) and loads them into memory, * passes them to the dbclient-binary (the dropbear-client-application), and * starts the ssh-connection In addition I'd like to know if an alternative to the ssh-config option (especially the ones for Host) exists for dropbear (and therefore if it is possible to create a host-specific config file for dropbear where I can specify e.g. the IP-address, the port and other details).