encrypt private keys for dropbear ssh-access

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:

dbclient -i <(cat .ssh/id_dropbear) user@server

So if you have a GPG encrypted .ssh/id_dropbear.gpg, you can write it as:

dbclient -i <(gpg --decrypt .ssh/id_dropbear.gpg) user@server

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 from dropbearconvert, you can apply the same principle:

$ dropbearconvert openssh dropbear 
    .ssh/id_openssh >(gpg --symmetric --output .ssh/id_dropbear.gpg)
Key is a ssh-rsa key
Wrote key to '/dev/fd/63'

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 that dropbearconvert 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.