#dropbear — Public Fediverse posts

@weirdunits aka #dropbear

@weirdunits aka #dropbear

Unlocking Fully Encrypted Servers over Tor

Remote servers should not have to choose between security and availability.

For years, the common compromise has been to expose SSH to the public Internet or to rely on VPNs and provider-specific KVM consoles whenever a LUKS-encrypted server reboots.

I believe there is a better approach.

By combining LUKS, Tor Onion Services, and a lightweight SSH server running directly inside the initramfs, it is possible to build servers that remain fully encrypted at rest, yet can always be unlocked remotely without exposing any public management interface.

This article describes the concept and how it could evolve into a reusable feature for Infinito.Nexus.

The Problem

Full disk encryption protects data when a server is powered off.

However, after every reboot someone must enter the LUKS passphrase.

For remote dedicated servers this usually means one of the following:

• opening SSH to the Internet
• connecting through a VPN
• using a provider’s KVM/IPMI console
• booting into a rescue system

While remote unlocking via Dropbear inside the initramfs is already a well-known solution, it still typically relies on a publicly reachable IP address.

The Idea

Instead of exposing SSH publicly, start Tor directly inside the initramfs.

The boot sequence would look like this:

Server boots
        │
        ▼
Kernel + initramfs
        │
        ▼
Network initialization
        │
        ▼
Tor starts
        │
        ▼
Temporary Onion Service appears

unlock-xxxxxxxx.onion
        │
        ▼
SSH via Tor
        │
        ▼
cryptsetup luksOpen
        │
        ▼
Root filesystem unlocked
        │
        ▼
Operating system boots
        │
        ▼
Temporary Onion Service disappears

The administrator simply connects through Tor:

torsocks ssh [email protected]

After entering the LUKS passphrase, the operating system continues booting normally.

Separate Identities for Boot and Runtime

One of the strongest aspects of this design is that boot-time and runtime use different Onion identities.

Boot environment

• dedicated Ed25519 key
• dedicated Onion address
• only SSH
• exists only during boot

Example:

unlock-xxxxxxxx.onion

Runtime environment

Once the operating system has booted:

• the initramfs exits
• Tor inside initramfs stops
• a new Tor instance starts
• completely different Onion addresses become available

For example:

ssh-xxxxxxxx.onion
cloud-xxxxxxxx.onion
matrix-xxxxxxxx.onion
mail-xxxxxxxx.onion

The unlock address simply disappears.

This cleanly separates the trust boundaries between the bootloader environment and the running operating system.

Why Tor?

Using Tor instead of exposing SSH directly provides several advantages:

• no public IP address required
• no exposed SSH port
• no VPN infrastructure
• works behind NAT or Carrier-Grade NAT
• management interface is only reachable through the Tor network
• additional network privacy
• ideal for self-hosted infrastructure

This is particularly attractive for servers hosted in data centers where administrators rarely have physical access.

What Happens After a Crash?

Whenever the server reboots:

1. the initramfs starts
2. networking is initialized
3. Tor publishes the temporary Onion Service
4. you connect via SSH
5. you unlock LUKS
6. the server continues booting

No KVM console.

No VPN.

No public SSH endpoint.

Only Tor.

Of course, catastrophic failures such as a broken initramfs or missing network drivers still require traditional recovery methods such as a rescue system or KVM.

Existing Building Blocks

Most of the required components already exist today.

My repository hetzner-arch-luks demonstrates how to deploy Arch Linux with full disk encryption on Hetzner servers and configure remote unlocking via SSH during the initramfs stage.

Repository:

https://github.com/kevinveenbirkenbach/hetzner-arch-luks

Another project, linux-image-manager, automates the creation and customization of Linux images and could serve as the foundation for embedding Tor, Dropbear/TinySSH, and the required initramfs configuration into reusable images.

Repository:

https://github.com/kevinveenbirkenbach/linux-image-manager

Together, these repositories provide much of the groundwork required for a fully automated implementation.

Future Integration into Infinito.Nexus

I envision this becoming a native feature of Infinito.Nexus.

Provisioning a server could automatically:

• install Arch Linux
• configure LUKS full disk encryption
• generate an initramfs containing:
  • Tor
  • Dropbear or TinySSH
  • cryptsetup
• create a dedicated boot-time Onion Service
• automatically switch to permanent runtime Onion Services after successful boot

From the administrator’s perspective, recovering a rebooted server would be as simple as:

torsocks ssh root@unlock-<hostname>.onion

Enter the passphrase.

The server continues booting.

Nothing is ever exposed to the public Internet.

Looking Ahead

This concept combines three mature technologies:

• LUKS
• Tor Onion Services
• Remote initramfs unlocking

While each technology already exists independently, integrating them into a seamless provisioning workflow could significantly improve the security and usability of encrypted self-hosted infrastructure.

For projects focused on digital sovereignty and privacy, removing the need for publicly exposed management interfaces is a natural next step.

you'd be angry too if you had to live here 😆🥶🐨 #dropbear #blueis

you'd be angry too if you had to live here 😆🥶🐨 #dropbear #blueis

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

When two Hetzner servers died at the same time

On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

Several hours went into hypotheses that turned out to be wrong:

• The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
• PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
• Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
• Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
• Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

What it almost certainly was

Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

• Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
• New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

Why it matters for anyone running this stack

If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

Tooling

While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

→ github.com/kevinveenbirkenbach/hetzner-arch-luks

Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

@imalcolm

Worse still, I have heard that Chinese pandas are at practice falling out of trees. You just have to go onto YouTube or similar and there’s lots of seemingly funny videos of them doing this.

In reality they’re not as dumb as they look and they have been inspired by the Australian drop bear. Imagine one tonne of panda landing on from a height of ten or so metres! 😩😱😱

So far the Chinese ambassador has been too polite to say anything to us about it but it looks like we won’t be getting any more pandas from China in the near future.

#panda #DropBear #China

@imalcolm

Worse still, I have heard that Chinese pandas are at practice falling out of trees. You just have to go onto YouTube or similar and there’s lots of seemingly funny videos of them doing this.

In reality they’re not as dumb as they look and they have been inspired by the Australian drop bear. Imagine one tonne of panda landing on from a height of ten or so metres! 😩😱😱

So far the Chinese ambassador has been too polite to say anything to us about it but it looks like we won’t be getting any more pandas from China in the near future.

#panda #DropBear #China

My favourite Australian character trait is the willingness to jump in on a lie in order to trick someone (in good fun).

This is best shown by dropbears*, where any Aussie will happily join in on sharing how terrifying they are, how weird it is that no one outside Aus knows about them, the importance of eating vegemite as a deterrent, etc.

I love that my MPIC friends have gotten fully on board with this, happily rabbiting on about dropbears and their risks. It warms my heart and makes me feel like home!

* this is not to imply that dropbears are not real. Of course they are.

#DropBear #migrantLife #Australia

My favourite Australian character trait is the willingness to jump in on a lie in order to trick someone (in good fun).

This is best shown by dropbears*, where any Aussie will happily join in on sharing how terrifying they are, how weird it is that no one outside Aus knows about them, the importance of eating vegemite as a deterrent, etc.

I love that my MPIC friends have gotten fully on board with this, happily rabbiting on about dropbears and their risks. It warms my heart and makes me feel like home!

* this is not to imply that dropbears are not real. Of course they are.

#DropBear #migrantLife #Australia

Bonus: I can wake up the desktop through Home Assistant.

And with VPN through Wireguard I then have access to my desktop system, its files and services that I need in rare cases.

I used this article
https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/ from [email protected] . Thank you.

2/2

#homeassistant #cryptsetup #dropbear #ubuntu

Bonus: I can wake up the desktop through Home Assistant.

And with VPN through Wireguard I then have access to my desktop system, its files and services that I need in rare cases.

I used this article
https://www.cyberciti.biz/security/how-to-unlock-luks-using-dropbear-ssh-keys-remotely-in-linux/ from [email protected] . Thank you.

2/2

#homeassistant #cryptsetup #dropbear #ubuntu

Today's desktop computer challenge: For the case I need access to my home desktop from remote, I trigger boot through wake on LAN and then remotely unlock the encrypted hard disks through SSH.

The challenge: Two encrypted hard disks. Solution: For the second hard drive add a key file located on the first hard disk as additional slot through cryptsetup, update the configuration in `/etc/crypttab`. Done.

1/2

#ubuntu #dropbear #cryptsetup #wol

Today's desktop computer challenge: For the case I need access to my home desktop from remote, I trigger boot through wake on LAN and then remotely unlock the encrypted hard disks through SSH.

The challenge: Two encrypted hard disks. Solution: For the second hard drive add a key file located on the first hard disk as additional slot through cryptsetup, update the configuration in `/etc/crypttab`. Done.

1/2

#ubuntu #dropbear #cryptsetup #wol

TIL if you Google for “drop bear” there’s a little #EasterEgg

#dropbear #australia

#SSH-Server #Dropbear erlaubt Rechteausweitung | Security https://www.heise.de/news/SSH-Server-Dropbear-erlaubt-Rechteausweitung-11119207.html #Patchday #OpenWRT

#SSH-Server #Dropbear erlaubt Rechteausweitung | Security https://www.heise.de/news/SSH-Server-Dropbear-erlaubt-Rechteausweitung-11119207.html #Patchday #OpenWRT

As most e.g. #OpenWRT devices use #dropbear just for root anyway and not for other users, this should not be critical issue for most installations in the real world, right? Or do I miss something?

https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2025q4/002390.html

As most e.g. #OpenWRT devices use #dropbear just for root anyway and not for other users, this should not be critical issue for most installations in the real world, right? Or do I miss something?

https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2025q4/002390.html

#Dropbear (Date TBC) 🐨
A group of US tourists on a cheap Aussie outback tour discover the scam's fake dropbear attack has led them into the lair of a real, flesh-hungry koala king and his rabid army.
#CreatureFeature #FilmsWithBite #FilmMastodon 📽️ 🎬

#Dropbear (Date TBC) 🐨
A group of US tourists on a cheap Aussie outback tour discover the scam's fake dropbear attack has led them into the lair of a real, flesh-hungry koala king and his rabid army.
#CreatureFeature #FilmsWithBite #FilmMastodon 📽️ 🎬

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#Devuan 6

#GhostPC updated to #Devuan 6! Some minor issues with #Dropbear and #SHH but I already fixed them!

And now with the saint power of #Excalibur I will defeat the evil rein of #Systemshit... 😂

Теневой союз: кто такие Cloaked Shadow

Хабр, всем привет! Меня зовут Никита Полосухин, я старший системный аналитик центра мониторинга и реагирования на кибератаки RED Security SOC. Сегодня хочу продолжить нашу историю об открытии новых (новых ли?) плохих парней (и, вероятно, девушек), которые очень любят взламывать российские компании. В июне мы рассказали о группировке Cloaked Shadow, которая характеризовалась обширным инструментарием, продвинутыми методами сокрытия и в целом высоким техническим уровнем. После этого мы получили возможность собрать и проанализировать новые данные и ранее не встречавшиеся образцы вредоносного программного обеспечения (ВПО), что помогло сделать много интересных выводов. Добро пожаловать под кат.

https://habr.com/ru/companies/ru_mts/articles/958950/

#Cloaked_Shadow #GOFEE #Vasilek #CyberpartisansBY #ReverseSocks5 #dropbear #Reversessh

Dear #NetBSD friends, it is possible using #dropbear on NetBSD as it #Linux, to unlock an #encrypted disk at boot even if remotely?

Thanks... 🙏

@ralphruthe Ja, der Löwe ist etwas missglückt. Der #Dropbear ist aber richtig gut geworden!

#DropbearSSH 2025.88 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

#DropbearSSH 2025.88 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

#DropbearSSH 2025.87 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

#DropbearSSH 2025.87 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

The Australian drop bear is a fictional carnivorous creature tied to local folklore, blending humor with cultural storytelling. #Dropbear #Australia https://connectparanormal.net/2025/01/15/unraveling-the-myth-of-the-australian-drop-bear/

#DropbearSSH 2024.86 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

#DropbearSSH 2024.86 has been released (#Dropbear / #SSH / #SecureShell / #SecureShellProtocol / #SSHServer / #SSHClient) https://matt.ucc.asn.au/dropbear/dropbear.html

Dropbear SSH 不會讀 /etc/environment 的問題

在 Raspberry Pi 上追問題一路找原因發現的，起因是 Dropbear SSH 預設不支援 PAM，所以不會觸發 PAM 會在登入時讀 /etc/environment 的設計。

其中 PATH 變數比較特別，Dropbear SSH 預設會塞很基本的值進去：

/* The default path. This will often get replaced by th

https://blog.gslin.org/archives/2024/10/25/12049/dropbear-ssh-%e4%b8%8d%e6%9c%83%e8%ae%80-etc-environment-%e7%9a%84%e5%95%8f%e9%a1%8c/

#Computer #Murmuring #Network #Programming #Security #Software #dropbear #environment #path #shell #ssh

Dropbear SSH 不會讀 /etc/environment 的問題

在 Raspberry Pi 上追問題一路找原因發現的，起因是 Dropbear SSH 預設不支援 PAM，所以不會觸發 PAM 會在登入時讀 /etc/environment 的設計。

其中 PATH 變數比較特別，Dropbear SSH 預設會塞很基本的值進去：

/* The default path. This will often get replaced by th

https://blog.gslin.org/archives/2024/10/25/12049/dropbear-ssh-%e4%b8%8d%e6%9c%83%e8%ae%80-etc-environment-%e7%9a%84%e5%95%8f%e9%a1%8c/

#Computer #Murmuring #Network #Programming #Security #Software #dropbear #environment #path #shell #ssh

@Brad_whitecross

#DropBear Incidents are more likely to happen during the mating season

@Brad_whitecross

#DropBear Incidents are more likely to happen during the mating season

⬆️ #DropBear@theblower.au @galad @serge @palestine @israel

At #DropBear’s insistence,
>> I asked my friend #Google, “How is the form of #Zionism that spawned #Israel characterised by #racism and #bloodlust?”

And now I’m trapped forever in a Google #AI database, tagged as an #antisemite

⬆️ #DropBear@theblower.au @galad @serge @palestine @israel

#HitAndRun. A very very quick #seppuku by DropBear!

He was posting his OPINION as fact, and doubled down with “yes and yes” two posts earlier when I challenged him.

Good riddance!

@pixelpusher220 #quokkas are definitely top of #straya's cute range :awesome: :blobcat_hearthug: but #wombats are actually cuddly, unlike #koalas and their close cousin the #dropbear 😁 @KingShawn

@pixelpusher220 #quokkas are definitely top of #straya's cute range :awesome: :blobcat_hearthug: but #wombats are actually cuddly, unlike #koalas and their close cousin the #dropbear 😁 @KingShawn

#Festplattenverschlüsselung auf einem #Server unter #Linux:

Ist #Dropbear in der #initramfs noch das Mittel der Wahl oder gibt es andere, bessere Ansätze?

#Festplattenverschlüsselung auf einem #Server unter #Linux:

Ist #Dropbear in der #initramfs noch das Mittel der Wahl oder gibt es andere, bessere Ansätze?

Contrary to popular belief, drop bears are more closely related to the bunyip than to koalas.

Like the bunyip it is know to also release a loud bellowing roar when devouring human flesh.

Some people today foolishly believe that sound to be a Botaurus poiciloptilus aka Australasian Bittern.

#DropBear #NightmareFuel #Bunyip #MythBusted

Apparently using #dropbear to unlock #LUKS on the #RaspberryPi 3B+ (and maybe others) will error out on boot with "ipconfig: no devices to configure" unless you insert a "sleep 4" after the "wait_for_udev 10" around line 300 in /usr/share/initramfs-tools/scripts/functions. It doesn't wait long enough for the network to come up. Neat. 😌

@brokenix it's been quite a while that #Dropbear isn't the default in #NixOS' #initrd anymore. See this commit for more details and the reasoning behind this decision:
https://github.com/NixOS/nixpkgs/commit/d930466b7728e5515991cb73c060fc3f32bdc001

#OpenSSH

Dear #Australia,

It is time to put a stop to the black-market #dropbear export crime rings! Michigan is being overrun with abandoned dropbear cubs after their idiot buyers realize they're not koalas!

You'd think they'd die in the Michigan winters. They become meaner. Lacking access to vegemite, they start eating deer, squirrel, and other critters.

STOP the ILLEGAL export of dropbear cubs! They have no place anywhere other than Australia.

Don't make us send hodags to Australia!

~Michigander

Waaahh ... Ich hab jetzt 15 Minuten rumprobiert und gerätselt, warum ich bei #rsync die Meldung "protocol version mismatch -- is your shell clean?" bekomme. Natürlich war die Shell clean, rsync auf beiden Seiten auch auf derselben Version. Dann ist mir aufgefallen, dass der Sender nicht #openssh, sondern #dropbear benutzt. #SSH

Nevermind bringing back the Thylacine, scientists should go the Full Tim and bring back Thylacoleo.

#australia #palentology #dropbear