31–40 of 128 posts
tinysshd doesn't implement unsafe features (such as password or hostbased authentication) Isn't password support useful for shared devices, like printers and routers? How would one enroll his personal keys on something like a car?
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…
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…
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.
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…
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.
Earlier quoted context omitted.
Dropbear ssh is very useful when you have a full disk encryption on a remote server and want to be able to decrypt it after a reboot.
There's technically no reason OpenSSHd can't also be used in this context. Maybe 2 decades ago there was a legitimate performance/disk space reason which is why Dropbear was preferred for this use case (and the convention remains to do this day), but nowadays the couple megabytes of difference in your initrd between using Dropbear and OpenSSH won't matter.
For initrd you generally prefer static binaries. Not saying that OpenSSHd doesn't build statically, but having less code and dependencies makes it easier to statically compile.
But yes, technically there is no reason to not use OpenSSHd, but in practice having a smaller and more self contained binary helps considering that you would want the bare minimum during initrd.
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…
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…
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.
In light of this post outlining a bug in early CC licenses: https://doctorow.medium.com/a-bug-in-early-creative-commons-...
Discussed here: https://news.ycombinator.com/item?id=39610509
Does this need updating?
EDIT: based on some discussion, it does need updating, but not for the reason I thought. I filed a suggestion here: https://github.com/janmojzis/tinyssh/issues/85
Earlier quoted context omitted.
There's technically no reason OpenSSHd can't also be used in this context. Maybe 2 decades ago there was a legitimate performance/disk space reason which is why Dropbear was preferred for this use case (and the convention remains to do this day), but nowadays the couple megabytes of difference in your initrd between using Dropbear and OpenSSH won't matter.
> There's technically no reason OpenSSHd can't also be used in this context. For initrd you generally prefer static binaries. Not saying that OpenSSHd doesn't build statically, but having less code and dependencies makes it easier to statically compile. But yes, technically there is no reason to not use OpenSSHd, but in practice having a smaller and more self contained binary helps considering that you would want the…