#cryptsetup — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cryptsetup, aggregated by home.social.
-
Teach me how to backup a layered volume
https://piefed.blahaj.zone/c/techsupport/p/875815/teach-me-how-to-backup-a-layered-volume
-
Teach me how to backup a layered volume
https://piefed.blahaj.zone/c/techsupport/p/875815/teach-me-how-to-backup-a-layered-volume
-
Teach me how to backup a layered volume
https://piefed.blahaj.zone/c/techsupport/p/875815/teach-me-how-to-backup-a-layered-volume
-
Teach me how to backup a layered volume
https://piefed.blahaj.zone/c/techsupport/p/875815/teach-me-how-to-backup-a-layered-volume
-
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 disappearsThe 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.onionRuntime 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.onionThe 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:
- the initramfs starts
- networking is initialized
- Tor publishes the temporary Onion Service
- you connect via SSH
- you unlock LUKS
- 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>.onionEnter 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.
#ArchLinux #cryptsetup #Cybersecurity #DevOps #DigitalSovereignty #DiskEncryption #Dropbear #FullDiskEncryption #Hetzner #InfinitoNexus #InfrastructureAsCode #initramfs #Linux #LinuxSecurity #LUKS #OnionServices #OpenSource #Privacy #RemoteLUKSUnlock #RemoteServerManagement #RemoteUnlock #SecureBoot #SelfHostedInfrastructure #SelfHosting #ServerSecurity #SSHOverTor #TinySSH #Tor #TorHiddenServices -
I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:
https://anisse.astier.eu/keyscript-to-socket-activation.html
-
I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:
https://anisse.astier.eu/keyscript-to-socket-activation.html
-
I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:
https://anisse.astier.eu/keyscript-to-socket-activation.html
-
I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:
https://anisse.astier.eu/keyscript-to-socket-activation.html
-
I documented how I replaced the Debian crypttab `keyscript` with systemd socket activation:
https://anisse.astier.eu/keyscript-to-socket-activation.html
-
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/n
-
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
-
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
-
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/n
-
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
-
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/n
-
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
-
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
-
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/n
-
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
-
LUKS/Fedora question: Does anybody know if there is a way to increase the number of passphrase attempts to unlock the encrypted partition at boot before cryptsetup failure ?
-
LUKS/Fedora question: Does anybody know if there is a way to increase the number of passphrase attempts to unlock the encrypted partition at boot before cryptsetup failure ?
-
LUKS/Fedora question: Does anybody know if there is a way to increase the number of passphrase attempts to unlock the encrypted partition at boot before cryptsetup failure ?
-
My experience with #FlashDrives recently has been mixed. I have no problem in encrypting them with #LUKS, using #cryptsetup or with formatting a partition with #Btrfs, for instance, using #gparted and doing other tinkering with #Gnome #disks. But the problem has been with the actual drives themselves. The cheaper ones seem to have quite a few bad sectors, etc. and so they’re not really reliable for medium term storage.
1/2
-
My experience with #FlashDrives recently has been mixed. I have no problem in encrypting them with #LUKS, using #cryptsetup or with formatting a partition with #Btrfs, for instance, using #gparted and doing other tinkering with #Gnome #disks. But the problem has been with the actual drives themselves. The cheaper ones seem to have quite a few bad sectors, etc. and so they’re not really reliable for medium term storage.
1/2
-
My experience with #FlashDrives recently has been mixed. I have no problem in encrypting them with #LUKS, using #cryptsetup or with formatting a partition with #Btrfs, for instance, using #gparted and doing other tinkering with #Gnome #disks. But the problem has been with the actual drives themselves. The cheaper ones seem to have quite a few bad sectors, etc. and so they’re not really reliable for medium term storage.
1/2
-
My experience with #FlashDrives recently has been mixed. I have no problem in encrypting them with #LUKS, using #cryptsetup or with formatting a partition with #Btrfs, for instance, using #gparted and doing other tinkering with #Gnome #disks. But the problem has been with the actual drives themselves. The cheaper ones seem to have quite a few bad sectors, etc. and so they’re not really reliable for medium term storage.
1/2
-
My experience with #FlashDrives recently has been mixed. I have no problem in encrypting them with #LUKS, using #cryptsetup or with formatting a partition with #Btrfs, for instance, using #gparted and doing other tinkering with #Gnome #disks. But the problem has been with the actual drives themselves. The cheaper ones seem to have quite a few bad sectors, etc. and so they’re not really reliable for medium term storage.
1/2
-
In case someone else is wondering why linux
lukshard disk encryption is usually within alvmcontainer: that way you only need one password to unlock multiple partitions.(found out the hard way)
-
In case someone else is wondering why linux
lukshard disk encryption is usually within alvmcontainer: that way you only need one password to unlock multiple partitions.(found out the hard way)
-
In case someone else is wondering why linux
lukshard disk encryption is usually within alvmcontainer: that way you only need one password to unlock multiple partitions.(found out the hard way)
-
In case someone else is wondering why linux
lukshard disk encryption is usually within alvmcontainer: that way you only need one password to unlock multiple partitions.(found out the hard way)
-
In case someone else is wondering why linux
lukshard disk encryption is usually within alvmcontainer: that way you only need one password to unlock multiple partitions.(found out the hard way)
-
So today I tired #mkfs.btrfs and this works. I was using #gparted, which can’t create #encrypted file systems and so I created a blank (cleared) one, used #cryptsetup to create the #encryption on the device, and then created the brtrfs file system.
-
So today I tired #mkfs.btrfs and this works. I was using #gparted, which can’t create #encrypted file systems and so I created a blank (cleared) one, used #cryptsetup to create the #encryption on the device, and then created the brtrfs file system.
-
So today I tired #mkfs.btrfs and this works. I was using #gparted, which can’t create #encrypted file systems and so I created a blank (cleared) one, used #cryptsetup to create the #encryption on the device, and then created the brtrfs file system.
-
So today I tired #mkfs.btrfs and this works. I was using #gparted, which can’t create #encrypted file systems and so I created a blank (cleared) one, used #cryptsetup to create the #encryption on the device, and then created the brtrfs file system.
-
So today I tired #mkfs.btrfs and this works. I was using #gparted, which can’t create #encrypted file systems and so I created a blank (cleared) one, used #cryptsetup to create the #encryption on the device, and then created the brtrfs file system.
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
Does someone have a working #nixos setup where they decrypt their drive via #cryptsetup that they access remotely via #tailscale?
That's what I am building for my new working machine.
Also WakeOnLan (via local network though).
:boost_ok: #followerpower
-
USBのケースに2.5インチHDDを?
?れて初期化しました．
LUKSで暗号化のためにCryptsetupを，透過圧縮，重複排除も使いたいということでBtrFSを利用しました．
[…]
https://matoken.org/blog/2024/11/12/initialize-usb-hdd-with-luks-btrfs/
-
Восстановление данных с зашифрованного Linux тома с помощью cryptsetup
В этой статье мы разберем восстановление данных с зашифрованного с помощью LUKS тома NAS. Внимание : в самом худшем случае для восстановления данных этим способом потребуется свободное место равное двум объемам зашифрованного раздела. Например, если у вас есть зашифрованный раздел на 1 ТБ, то необходимо иметь 2 ТБ свободного места. В лучшем случае (незначительные повреждения) понадобится один объем свободного дискового пространства. Также обращаем внимание, что вам НУЖНО ЗНАТЬ пароль, который использовался для шифрования тома Для примера мы будем использовать диск от QNAP с зашифрованном разделом. 1. Подключаем диск от QNAP к компьютеру с помощью USB или SATA. После чего нужно любым доступным способом создать образ зашифрованного раздела. Для примера мы будем использовать программу Vолга. Выбираем раздел QNAP и начинаем создание образа. Мы советуем сохранить образ в формате .img (посекторный RAW образ) на любой внешний диск.
https://habr.com/ru/articles/855290/
#Шифрование #luks #cryptsetup #зашифрованный_раздел #восстановление_данных #расшифровка_данных
-
Восстановление данных с зашифрованного Linux тома с помощью cryptsetup
В этой статье мы разберем восстановление данных с зашифрованного с помощью LUKS тома NAS. Внимание : в самом худшем случае для восстановления данных этим способом потребуется свободное место равное двум объемам зашифрованного раздела. Например, если у вас есть зашифрованный раздел на 1 ТБ, то необходимо иметь 2 ТБ свободного места. В лучшем случае (незначительные повреждения) понадобится один объем свободного дискового пространства. Также обращаем внимание, что вам НУЖНО ЗНАТЬ пароль, который использовался для шифрования тома Для примера мы будем использовать диск от QNAP с зашифрованном разделом. 1. Подключаем диск от QNAP к компьютеру с помощью USB или SATA. После чего нужно любым доступным способом создать образ зашифрованного раздела. Для примера мы будем использовать программу Vолга. Выбираем раздел QNAP и начинаем создание образа. Мы советуем сохранить образ в формате .img (посекторный RAW образ) на любой внешний диск.
https://habr.com/ru/articles/855290/
#Шифрование #luks #cryptsetup #зашифрованный_раздел #восстановление_данных #расшифровка_данных
-
Восстановление данных с зашифрованного Linux тома с помощью cryptsetup
В этой статье мы разберем восстановление данных с зашифрованного с помощью LUKS тома NAS. Внимание : в самом худшем случае для восстановления данных этим способом потребуется свободное место равное двум объемам зашифрованного раздела. Например, если у вас есть зашифрованный раздел на 1 ТБ, то необходимо иметь 2 ТБ свободного места. В лучшем случае (незначительные повреждения) понадобится один объем свободного дискового пространства. Также обращаем внимание, что вам НУЖНО ЗНАТЬ пароль, который использовался для шифрования тома Для примера мы будем использовать диск от QNAP с зашифрованном разделом. 1. Подключаем диск от QNAP к компьютеру с помощью USB или SATA. После чего нужно любым доступным способом создать образ зашифрованного раздела. Для примера мы будем использовать программу Vолга. Выбираем раздел QNAP и начинаем создание образа. Мы советуем сохранить образ в формате .img (посекторный RAW образ) на любой внешний диск.
https://habr.com/ru/articles/855290/
#Шифрование #luks #cryptsetup #зашифрованный_раздел #восстановление_данных #расшифровка_данных
-
TIL: If you want to `cryptsetup open` a BitLocker encrypted drive using the recovery key (8 blocks of 6 digits each), make sure to enter it _with_ the dashes between each block of digits, else it won't be recognized.
-
TIL: If you want to `cryptsetup open` a BitLocker encrypted drive using the recovery key (8 blocks of 6 digits each), make sure to enter it _with_ the dashes between each block of digits, else it won't be recognized.
-
TIL: If you want to `cryptsetup open` a BitLocker encrypted drive using the recovery key (8 blocks of 6 digits each), make sure to enter it _with_ the dashes between each block of digits, else it won't be recognized.
