I'd like to use dropbear
as an alternative, minimal ssh-server and -client. dropbear
allows the use of private-public-keys for ssh-access, although the keys are not identical to the ones used by openssh
and have to be converted using the dropbearconvert
-command (which is easy to do).
The issue I'm having is that dropbear
doesn't natively support encrypted private keys. But leaving unencrypted ssh-keys on my laptop is something I'd like to avoid out of principle.
Therefore my question: does anyone have any good ideas on how to circumvent that issue and have a method (script?) that:
- decrypts the keys I use for dropbear (e.g. using
gnupg
) and loads them into memory, - passes them to the
dbclient
-binary (thedropbear
-client-application), and - starts the ssh-connection
In addition I'd like to know if an alternative to the ssh
-config option (especially the ones for Host
) exists for dropbear (and therefore if it is possible to create a host-specific config file for dropbear where I can specify e.g. the IP-address, the port and other details).
Best Answer
It appears that
dbclient
is entirely willing to read the private key from a named pipe or FIFO.So with bash's process substitution, you can write:
So if you have a GPG encrypted
.ssh/id_dropbear.gpg
, you can write it as:And after entering your decryption password,
dbclient
logs in using your GPG encrypted private key. So that part works fine.The main issue here is that if you already stored
.ssh/id_dropbear
unencrypted before that, it could be recovered forensically. To encrypt a key on the fly fromdropbearconvert
, you can apply the same principle:But it does not seem to be too useful in practice, since
dropbearconvert
also offers only very limited support for OpenSSH's encrypted private keys. For this example I had to specially create an OpenSSH key thatdropbearconvert
understands...Unfortunately, this trick does not seem to work at all for the
dropbearkey
command, which for some reason insists on writing to a temporary file and renaming it, circumventing the pipe entirely.Thus it appears you have no choice but to generate the private key in
tmpfs
first (like in/dev/shm
or from a live cd), and encrypt it from there.