@UweMenges many thanks for this great PR! It makes definitely sense

First of all I would like to have some kind of simple/easy testing way, in order to be able to test/verify such things easier. I would try to build some vagrant boxes in the full-encrypted setup, so we would get a Vagrantfile here. After we have a such thing, I would definitely like to test this PR and to merge it. It will take some time, sorry for that, I hope thats Ok for you

Incorporating sshd will allow me to remote call into my globally available sshd service tunnelling local ports of protected host for LUKS secret input. And that's what I am looking for! <3

FYI, I was looking for a way to ssh into dracut and Dropbear lacking ed25519 support was a show stopper for me to use dracut-crypt-ssh. Thus I created dracut-ssh that uses OpenSSH sshd instead of dropbear:

https://github.com/gsauthof/dracut-sshd

@gsauthof thanks for pointing me to your project. I really like the simplifications it introduces, like using a proper systemd service for the sshd and the the tty password helper instead of the /dev/console hack. I'd actually propose merging that and collaborating (but we'd have to converge on the licenses, dracut-crypt-ssh is GPLv2 in an attempt to have it mergeable into dracut in the future).
If that's a discussion you think is worthwhile having, let me know and we could move it to a new issue.

I have hope that merging project would not force using systemd.

When this starts requiring systemd it would become useless to me and many others.

It seems that lack of testing is the main reason to not merge the PR. @artem-sidorenko any progress on that?
I'm on a systemd distro so @gsauthof's attempt probably works for me as well.

@UweMenges sorry for a such delay, this is due to some changes in my life and a total lack of time. I invoked an email discussion with @gsauthof @rbu regarding the future of dracut-crypt-ssh and dracut-sshd. Depending on the outcome of this discussion I would decide if I would try to find the time for this PR and/or other topics.

Sorry again and thank you for great work and patience!

#43

This is not a bad idea, but there are a few issues that should be addressed if you're still interested.

1. The default SSH keys should not be pulled from /etc/ssh. Dracut tends to set a restrictive umask by default, but in many cases (like with systemd-boot) the initramfs is readable by any user. This will leak SSH private keys to anybody that can read out the initramfs. The default key files for the initramfs ought to come from a separate directory, and let the user override them if desired.
2. All of the variables that are currently prefixed dropbear_ will be misnamed if we are sshd-agnostic. To support OpenSSH, we should use generic variable names (maybe something like crypt_ssh_* instead of dropbear_*) and have a migration path so old configurations don't break.
3. The systemd section of the README seems unrelated to this change.

I'm using https://github.com/gsauthof/dracut-sshd in the meanwhile, so I'm not actively pushing this PR.
Feel free to close and/or take whatever you want from it.

I don't see the initramfs permission issue on my system, and I don't know systemd-boot, but the initramfs might contain sensitive data other than the ssh keys, so maybe this is an issue for systemd-boot?

As far as I can see, the default key to use is GENERATED in module-setup.sh#L35 in accordance to the recommendation in the README.md (but not in crypt-ssh.conf#L19, this PR contains a fix for that).

Thanks for letting me know. Closing for now.