3

I have a local machine running dropbear and I want to connect to a remote host running openssh without having to type the password every time.

I have found lots of documentation on how to do the reverse, and it seems easy because dropbear does support /etc/dropbear/authorized_keys. However what I want does not seem nearly as easy and I can't find any documentation on this.

I have tried copying /etc/dropbear/dropbear_rsa_host_key to the remote hosts .ssh/authorized_keys but that didn't work. So either I didn't do it right (very possible), or it can't be done that way.

I have tried generating keys on the remote host and then copying them into local's .ssh/, and adding the public to remote's .ssh/authorized_keys but that didn't work either.

I haven't been able to think of anything else to try, so I figured I'd try to ask someone more experienced than me.

TechnoSam
  • 131
  • 3

1 Answers1

0

A few things unclear from your question:

  • dbclient is the dropbear client program
  • dropbear/dbclient cannot natively read OpenSSH private key files so they have to be created using dropbearkey or converted using dropbearconvert

That said here is how to make a private key on the dropbear client machine and append the public key to the authorized_keys file on the OpenSSH server host.

mkdir ~/.ssh
dropbearkey -t ed25519 -f ~/.ssh/id_dropbear # this creates a private key in the default location for dbclient
#substitute the username and host on the following line and please note the use of both single quotes (') and back ticks (`)
dbclient username@host 'mkdir ~/.ssh; echo '`dropbearkey -y -f ~.ssh/id_dropbear | grep ssh `'>> ~/.ssh/authorized_keys; chmod 600 ~./ssh/authorized_keys'  # accept the hostkey and login using your password. You should be returned to the client prompt
dbclient username@host # client should automatically use the id_dropbear file for key authentication.

I tested this all on the two Debian 11 (bullseye) VMs, but it should work for any Linux OS using a standard-ish dropbear package.

Edit: Just a note to add that private keys should always be generated on the local machine and public keys copied to a remote. Private keys off of the local host are nearly always a security risk (except maybe encrypted backups).

Dave
  • 1
  • 1