nixos-unstable - luks ssh unlock bug

[ShiroDN]

Issue description

If I try to remotely unlock luks devices in stage 1 through ssh on unstable (19.03pre) it couses this error :

[tomas@w0:~]$ ssh root@192.168.12.123 -p 2222
~ # cryptsetup-askpass 
Passphrase for /dev/vda2: 
cat: can't open '/crypt-ramfs/device': No such file or directory
Passphrase for : 
Connection to 192.168.12.123 closed by remote host.
Connection to 192.168.12.123 closed.

But on 18.09beta output is:

[tomas@w0:~]$ ssh root@192.168.12.123 -p 2222
~ # cryptsetup-askpass 
Passphrase for /dev/vda2: 
Waiting 10 seconds for LUKS to request a passphrase...........
Connection to 192.168.12.123 closed by remote host.
Connection to 192.168.12.123 closed.

In the end it unlocks devices successfully in both cases, but in first case you are not sure if you entered right password or not, because it shows row Passphrase for : immediately after you enter the password without waiting 10 seconds like it does in second case. I tried to figure it out what is causing it and I think this error is caused by commit 8ab4cbd

Steps to reproduce

1. create luks encrypted devices
2. add initrd luks unlock config to /etc/nixos/configuration.nix:
   Example:

   boot.initrd.luks.devices = [
    {
      name = "roota";
      device = "/dev/vda2";
    }
    {
      name = "rootb";
      device = "/dev/vdb2";
    }
  ];

3. enable initrd ssh access
4. Try to unlock devices through ssh in initrd stage 1 on unstable (19.03pre) vs 18.09 with command cryptsetup-askpass

Technical details

• system: "x86_64-linux"
• host os: Linux 4.14.72, NixOS, 19.03pre153873.b7069ecbd66 (Koi)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.1.2
• channels(root): "nixos-19.03pre153873.b7069ecbd66"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[lopsided98]

I am also running into this issue, but my setup is somewhat different because I have a module that uses tinyssh (which supports ed25519 keys) instead of dropbear.

My module sets the SSH shell to a script which calls cryptsetup-askpass, but I don't see any equivalent code in nixpkgs for dropbear. I pretty sure I copied a lot of this code from nixpkgs, so I am wondering what I am missing. How do you have dropbear configured to call cryptsetup-askpass?

I looks like lots of changes were made to the LUKS code recently, and no one tested them with SSH unlocking.

[lopsided98]

The 18.09beta output appears to be the intended behavior. The nixos unstable output is an easily fixable bug introduced by #45998.

The way cryptsetup-askpass is currently designed, there is no way for it to know whether a passphrase was correct. It waits for the main unlock script to request a passphrase, and when it receives a passphrase from the user it writes it to a ramfs file which is read by the main unlock script (after a delay of up to 1 second). It then loops and waits for another password to be requested. If no password is requested after 10 seconds, it exits. That accounts for the last line of the 18.09beta output, although in your case dropbear was killed before the wait timed out.

If the password was incorrect the first time, you will get another password prompt for the same device, but no explicit notification that the first passphrase was incorrect. There is also the edge case where verifying the passphrase could take more than 10 seconds (e.g. due to a large number of hash iterations), in which case it would time out and you would have to reconnect to enter the passphrase again.

I think this is mainly a UX issue, as it is not clear what is happening unless you have looked at the code. Not having explicit confirmation of a correct or incorrect passphrase is confusing, and the message Waiting 10 seconds for LUKS to request a passphrase........... makes it sound like something went wrong.

@oxij What are your thoughts on this?

[lopsided98]

See #48229 for a fix for the cat: can't open '/crypt-ramfs/device': No such file or directory error.

Another UX issue: after entering an incorrect passphrase, wait_target prints - success when it receives another passphrase request.

[ShiroDN]

Actualy, I am unlocking manualy by invoking cryptsetup-askpass. I plan to migrate my home server from Archlinux to NixOS, so I am trying to test my setup in vps.

The 18.09beta output is alright. I paste it there only for comparison.

Thanks for the fix and tip on tinyssh, I was wondering why my ed25519 key didn't worked with dropbear at my first attempt.

[oxij]

Am I right to assume that the bulk of the problem (the loss of device name) is solved by #48229?

The way `cryptsetup-askpass` is currently designed, there is no way for it to know whether a passphrase was correct. It waits for the main unlock script to request a passphrase, and when it receives a passphrase from the user it writes it to a ramfs file which is read by the main unlock script (after a delay of up to 1 second). It then loops and waits for another password to be requested. If no password is requested after 10 seconds, it exits. That accounts for the last line of the 18.09beta output, although in your case dropbear was killed before the wait timed out.

Correct.

If the password was incorrect the first time, you will get another password prompt for the same device, but no explicit notification that the first passphrase was incorrect. There is also the edge case where verifying the passphrase could take more than 10 seconds (e.g. due to a large number of hash iterations), in which case it would time out and you would have to reconnect to enter the passphrase again.

Correct.

I think this is mainly a UX issue, as it is not clear what is happening unless you have looked at the code. Not having explicit confirmation of a correct or incorrect passphrase is confusing, and the message `Waiting 10 seconds for LUKS to request a passphrase...........` makes it sound like something went wrong.

Yeah, I guess I can just make the decryptor process in init to supply feedback to `cryptsetup-askpass` for a better UX there. Will do.

Another UX issue: after entering an incorrect passphrase, `wait_target` prints `- success` when it receives another passphrase

Well, it is a "waiting success", not a "cryptsetup success". But I agree it might be a bit confusing without reading the source.

[lopsided98]

Yes, the actual bug is solved #48229. I started looking into the UX issues because the new behavior confused me when I first saw it, but it really isn't a big deal once you realize how it works.

[fpletz]

Fixed by #48229.