7 ms·

tinyssh is great. One use case for it that people may not know about: using it during Linux boot so you can remotely unlock encrypted drives. I have a headless

tinyssh is great. One use case for it that people may not know about: using it during Linux boot so you can remotely unlock encrypted drives. I have a headless NAS server that uses dm-crypt/LUKS under ZFS. When I update my kernel/ZFS I remotely reboot the server, wait a few seconds, and then ssh into a tinyssh powered encryption key prompt to unlock the drives. (I am immediately booted from ssh, as tinyssh exits.) I can then ssh again a few seconds later and I'm hitting openssh on a fully booted machine that wasn't able to open the drives without my intervention. https://github.com/grazzolini/mkinitcpio-tinyssh https://github.com/grazzolini/mkinitcpio-tinyssh

gymbeaux 3y ago
Usually I use DropBear for this. Do you know if one is necessarily better than the other? DropBear I think is what RHEL docs recommend for remote boot disk decryption.
- bretthoerner 3y ago
  Ah, I've never used DropBear. I don't know how one could be better than another for my simple use case, honestly.
jethro_tell 3y ago
I use normal opensshd for this. No reason to support two ssh daemons when you can do it with one. The difference in size on your init image is minimal and you probably aren't even trying to optimize for space there. If you don't know the size of your rd off the top of your head then it almost certainly doesn't matter.
- bretthoerner 3y ago
  All fair, I guess I just landed on mkinitcpio-tinyssh first and it was my introduction to the idea, and only took a few seconds to setup. I'll switch to openssh if I ever have issues, but this has been working fine for many years, so I'm no rush.
  - jethro_tell 3y ago
    Makes sense. Probably more work to go off the beaten path then to maintain two configs
- streb-lo 3y ago
  Probably not more popular because (for reasons I do not know) the mkinitcpio hooks Arch Linux provides are only for tinyssh and dropbear: https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote_unlocking_of_root_(or_other)_partition https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote...
krab 3y ago
A tool based on Dropbear that does exactly this, automatically. https://github.com/ViktorStiskala/cryptsetup-ssh-unlocker https://github.com/ViktorStiskala/cryptsetup-ssh-unlocker
- teddyh 3y ago
  The documentation for Cryptsetup SSH unlocker states “To further limit the attack possibility, you should use monitoring and possibly disable SSH unlocker in the case of unexpected behavior.” Mandos has a built-in feature to deal with this, enabled by default. (Again, disclosure: I am the co-author of Mandos.)
forty 3y ago
Question: when remotely unlock the boot disk via ssh, how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys? At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :) [1] https://github.com/ANSSI-FR/ultrablue https://github.com/ANSSI-FR/ultrablue
- bretthoerner 3y ago
  > how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys? In my case, I can't. This is a NAS in my house and this is mostly to prevent me from having to go to another room and plug in a monitor and keyboard. (Also, I've done this from across the country after a power outage.) The threat vectors I'm protecting against are I guess mostly theft of the entire machine, or forgetting to wipe the drives when I eventually toss them out. Mostly, it's just fun practice because I'm a nerd and every drive should be encrypted. For my use-case, the auto-unlock-by-polling-a-specific-LAN-IP linked in this thread would probably be fine, for example.
  - jethro_tell 3y ago
    This is mostly me but the case that's the most common is that a disk can't be wiped because its dead. Gotta do that before hand.
    - aftbit 3y ago
      Well you can always drill holes in the platter, or hit them with a strong magnet, or just separate them and toss them in the trash. Unless you're fighting the NSA, you can probably get away with enough physical destruction to make recovery challenging.
      - jethro_tell 3y ago
        That doesn't work if you need to RMA the disk. So best to encrypt before you put anything on the disk
babuskov 3y ago
I thought that everyone has switched to Clevis + Tang for that? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening https://access.redhat.com/documentation/en-us/red_hat_enterp... It's fully automated and supposed to be much more secure. Has anyone got experience with it?
- traceroute66 3y ago
  > I thought that everyone has switched to Clevis + Tang for that? Clevis+Tang is good. There's also Keylime which takes a different approach to the same[1]. [1] https://keylime.dev/ https://keylime.dev/
- soraminazuki 3y ago
  IIUC whether that is secure depends on your threat model. For example, how good is automated unlocking compared to unencrypted drives in a homelab setup?
- ahepp 3y ago
  I've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?
  - babuskov 3y ago
    I guess it depends on your use case. If you rent a bunch of bare-metal servers at a remote location and you want restarts after updates to be fully automated, Clevis seems like a way to do. The whole idea is that once you cancel the server, you just remove it from Tang's list and the next customer who gets those hard drives cannot read them. AFAICT, systemd-cryptenroll requires that you have a USB key plugged into the machine, so someone with physical access would have to insert them at the start and remove when you're done with the server. With Clevis+Tang everything is software. Or am I missing something?
    - ahepp 3y ago
slug 3y ago
For debian/ubuntu users, there's also dropbear-initramfs package with same functionality (works with any fs luks/ext4/lvm/zfs/etc). https://packages.debian.org/bookworm/dropbear-initramfs https://packages.debian.org/bookworm/dropbear-initramfs https://packages.ubuntu.com/jammy/dropbear-initramfs https://packages.ubuntu.com/jammy/dropbear-initramfs
- justin_oaks 3y ago
  I've used this for several years now. It works well and is relatively easy to set up.
- teddyh 3y ago
  Note: Mandos is also in Debian and Ubuntu. (Obligatory disclaimer: I am a co-author of Mandos)
orev 3y ago
This is more or less the RedHat based solution to do this using openssh: https://github.com/gsauthof/dracut-sshd https://github.com/gsauthof/dracut-sshd https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd/ https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd...
teddyh 3y ago
There’s a non-interactive solution to rebooting safely with encrypted disks: Mandos <https://www.recompile.se/mandos https://www.recompile.se/mandos> Reboot your server while you sleep! Disclosure: I am a co-author of Mandos.
- jethro_tell 3y ago
  This is really cool. I'm going to give this a try!
1vuio0pswjnm7 3y ago
"tinyssh is great." Agreed. A static tinysshd works well for the small userlands I create.

gymbeaux 3y ago

Usually I use DropBear for this. Do you know if one is necessarily better than the other? DropBear I think is what RHEL docs recommend for remote boot disk decryption.

bretthoerner 3y ago
Ah, I've never used DropBear. I don't know how one could be better than another for my simple use case, honestly.

jethro_tell 3y ago

I use normal opensshd for this. No reason to support two ssh daemons when you can do it with one. The difference in size on your init image is minimal and you probably aren't even trying to optimize for space there. If you don't know the size of your rd off the top of your head then it almost certainly doesn't matter.

bretthoerner 3y ago
All fair, I guess I just landed on mkinitcpio-tinyssh first and it was my introduction to the idea, and only took a few seconds to setup. I'll switch to openssh if I ever have issues, but this has been working fine for many years, so I'm no rush.
- jethro_tell 3y ago
  Makes sense. Probably more work to go off the beaten path then to maintain two configs
streb-lo 3y ago
Probably not more popular because (for reasons I do not know) the mkinitcpio hooks Arch Linux provides are only for tinyssh and dropbear: https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote_unlocking_of_root_(or_other)_partition https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote...

krab 3y ago

A tool based on Dropbear that does exactly this, automatically. https://github.com/ViktorStiskala/cryptsetup-ssh-unlocker https://github.com/ViktorStiskala/cryptsetup-ssh-unlocker

teddyh 3y ago
The documentation for Cryptsetup SSH unlocker states “To further limit the attack possibility, you should use monitoring and possibly disable SSH unlocker in the case of unexpected behavior.” Mandos has a built-in feature to deal with this, enabled by default. (Again, disclosure: I am the co-author of Mandos.)

forty 3y ago

Question: when remotely unlock the boot disk via ssh, how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys? At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :) [1] https://github.com/ANSSI-FR/ultrablue https://github.com/ANSSI-FR/ultrablue

bretthoerner 3y ago
> how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys? In my case, I can't. This is a NAS in my house and this is mostly to prevent me from having to go to another room and plug in a monitor and keyboard. (Also, I've done this from across the country after a power outage.) The threat vectors I'm protecting against are I guess mostly theft of the entire machine, or forgetting to wipe the drives when I eventually toss them out. Mostly, it's just fun practice because I'm a nerd and every drive should be encrypted. For my use-case, the auto-unlock-by-polling-a-specific-LAN-IP linked in this thread would probably be fine, for example.
- jethro_tell 3y ago
  This is mostly me but the case that's the most common is that a disk can't be wiped because its dead. Gotta do that before hand.
  - aftbit 3y ago
    Well you can always drill holes in the platter, or hit them with a strong magnet, or just separate them and toss them in the trash. Unless you're fighting the NSA, you can probably get away with enough physical destruction to make recovery challenging.
    - jethro_tell 3y ago
      That doesn't work if you need to RMA the disk. So best to encrypt before you put anything on the disk

babuskov 3y ago

I thought that everyone has switched to Clevis + Tang for that? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening https://access.redhat.com/documentation/en-us/red_hat_enterp... It's fully automated and supposed to be much more secure. Has anyone got experience with it?

traceroute66 3y ago
> I thought that everyone has switched to Clevis + Tang for that? Clevis+Tang is good. There's also Keylime which takes a different approach to the same[1]. [1] https://keylime.dev/ https://keylime.dev/
soraminazuki 3y ago
IIUC whether that is secure depends on your threat model. For example, how good is automated unlocking compared to unencrypted drives in a homelab setup?
ahepp 3y ago
I've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?
- babuskov 3y ago
  I guess it depends on your use case. If you rent a bunch of bare-metal servers at a remote location and you want restarts after updates to be fully automated, Clevis seems like a way to do. The whole idea is that once you cancel the server, you just remove it from Tang's list and the next customer who gets those hard drives cannot read them. AFAICT, systemd-cryptenroll requires that you have a USB key plugged into the machine, so someone with physical access would have to insert them at the start and remove when you're done with the server. With Clevis+Tang everything is software. Or am I missing something?
  - ahepp 3y ago

slug 3y ago

For debian/ubuntu users, there's also dropbear-initramfs package with same functionality (works with any fs luks/ext4/lvm/zfs/etc). https://packages.debian.org/bookworm/dropbear-initramfs https://packages.debian.org/bookworm/dropbear-initramfs https://packages.ubuntu.com/jammy/dropbear-initramfs https://packages.ubuntu.com/jammy/dropbear-initramfs

justin_oaks 3y ago
I've used this for several years now. It works well and is relatively easy to set up.
teddyh 3y ago
Note: Mandos is also in Debian and Ubuntu. (Obligatory disclaimer: I am a co-author of Mandos)

orev 3y ago

This is more or less the RedHat based solution to do this using openssh: https://github.com/gsauthof/dracut-sshd https://github.com/gsauthof/dracut-sshd https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd/ https://copr.fedorainfracloud.org/coprs/gsauthof/dracut-sshd...

teddyh 3y ago

There’s a non-interactive solution to rebooting safely with encrypted disks: Mandos <https://www.recompile.se/mandos https://www.recompile.se/mandos> Reboot your server while you sleep! Disclosure: I am a co-author of Mandos.

jethro_tell 3y ago
This is really cool. I'm going to give this a try!

1vuio0pswjnm7 3y ago

"tinyssh is great." Agreed. A static tinysshd works well for the small userlands I create.