fetzerms
Decrease time until dropped to emergency shell
At this time the client will try for a fairly long time, until giving up. I reckon it would be much more useful to decrease this time significantly. One possible lever could be the variables in crypttab and another could be the TimeOut in SSH. If it's working, it's basically instant and if not, it's not going to change on it's own in the approximately 20 minutes the user is force to wait. Especially if they cannot access their workstation.
Maybe we should also mention tries= in crypptab. But I dont think that lowering the value below the default three tries.
I think there would be at least two loops of trial. One which happens some three times or so and another which happens another three times or so. The inner one being slowed down by a 60 second waiting period. In addition to a TimeOut of SSH itself, that would make some 3 * TimeOut * 3 . In case of TimeOut=100 that's 15 minutes.
One could also differentiate between the two cases of workstation and headless server. On a workstation this wating time should be rather low, however on a server it could be more useful for it to retry forever.
The problem could also dissolve, if there is a way to break the loops manually. There would be no waiting time at all and automated devices can happily try for all eternity.
The question on "how often should it loop" should be left to the settings in the crypttab file (tries option). Tho, we could propose a good default value. We might as well add variations of the timeout in the scripts/wiki that fit a specific kind of system better than another possible value (workstation vs. server).
Additionally we could read CRYPTTAB_TRIED, CRYPTTAB_OPTIONS to check how often we've been called and drop to askpass ourselves, without actually dropping to a shell.
I just realized, that adding the break kernel parameter drops to the shell instantly, which will allow for unlocking instantly. If one is using GRUB, this particular issue could be solved by an additional boot entry. I myself am using EFIStubs, so I'd need something a little different.
I'm not sure how much work it would mean to drop to askpass automatically. Do you know how to accomplish this?
If a specified threshold has been exceeded. I think we only need to execute:
/lib/cryptsetup/askpass "Please enter passphrase: " > /lib/cryptsetup/passfifo
But I'm not sure if we want to go this way.
I couldn't unlock using this command straight away. Perhaps I'm doing something wrong. However, I'm also not certain, whether we should go the way of dropping to askpass.
I don't mean to sound self-opinionated, but I think this is a fairly advanced setup. By now the documentation includes the cryptsetup open vda5 vda5_crypt command and if a user cannot manage executing a command like that, maybe they shouldn't try this in the first place. In that case this whole setup might do much more harm than good, if they manage to lose access to their data altogether.
However, I still think it's worthwhile to get the exact retry loop under control. I still think most of the time in the desktop case it won't help at all to retry for half an hour before giving up.
Yes. I agree on that - we should also keep things as simple as possible. The user himself should decide how often he wants to retry. We should mention the crypttab options, but I wouldnt go any further.
Sample Text: By default (debian) retrieving the key is tried for three times. This behavior can be adjusted by adding a "tries=" parameter to the crypttab line. Tries=0 tries indefinitely. Please see crypttab for more information.
sda5_crypt UUID=<uuid> none luks,tries=0,keyscript=/lib/cryptsetup/scripts/get_key_ssh # server
sda5_crypt UUID=<uuid> none luks,tries=1,keyscript=/lib/cryptsetup/scripts/get_key_ssh # workstation
Sounds good. Still I want to point out that, the loop is still rather time consuming. At this point the tries=1 and timeout=5, but it still tries 5 times.
I still haven't figured out where those values come from. But this might be important.
Yes, /usr/share/initramfs-tools/scripts/local-top/cryptroot houses this logic. I think we shouldn't mess with the code itself, however it seems strange, that it retries 5 times, although crypttab says otherwise. And that hardcoded failsleep=60 makes me kind of cringe though.