Dropbear not using SSH keys

Trimble-tech · 1 February 2023 19:17

Hello, I a default install of DietPi v8.13.2 on a Pi 4B, and am trying to setup SSH keys to connect to the Dropbear server (on Dietpi) from an OpenSSH client. The Pi4B is working well and connecting with passwords at the moment. Using keys, I am getting this error: dietpi@ip_address: Permission denied (publickey,password)

I saw a long-time bug in ssh-copy-id moves keys incorrectly to /etc/dropbear/authorized_keys, I successfully tricked it to put the keys into /home/dietpi/authorized_keys by making /etc/dropbear/authorized_keys a dietpi owned symlink. The permissions are as follows:

lrwxrwxrwx 1 dietpi dietpi 33 Feb 1 18:06 /etc/dropbear/authorized_keys → /home/dietpi/.ssh/authorized_keys
-rw------ 1 dietpi dietpi 96 Feb 1 18:42 /home/dietpi/.ssh/authorized_keys

I’ve set these permissions with chmod 600; 700 is giving the same result. I’m testing the keys by restarting Dropbear (sudo systemctl restart dropbear.service) or dietpi-services and then running ssh -o PasswordAuthentication=no dietpi@ip_address. The process gives the error dietpi@ip_address: Permission denied (publickey,password)..

With all of this said, I know Dropbear has issues with incorrect permissions so I tried addressing it; and I understand somewhere is a config file for Dropbear but I don’t know why keys would be blocked/not enabled.

As Dropbear is default here, I hope you may shed some wisdom so I can learn; I appreciate you reading this and hope to find a solution.

Joulinar · 1 February 2023 19:57

There is no need for any symbolic link. Just add your key for user dietpi into /home/dietpi/.ssh/authorized_keys

sudo chmod 700 /home/dietpi/.ssh
sudo chmod 600 /home/dietpi/.ssh/authorized_keys
sudo chown dietpi:dietpi /home/dietpi/.ssh/authorized_keys

We had similar a couple of weeks ago Dropbear Public Key Authentication

Trimble-tech · 1 February 2023 21:00

So, I started again on a fresh install, and followed these steps exactly with a new key. However, I am still getting the same issue; ssh is not allowing me to connect with the key. I know Dropbear should take the same public key as OpenSSH, but is there a caveat or something I’m missing?

Install Dietpi with Dropbear
Copied the keys with ssh and then to authorized_keys

cat ~/.ssh/dropbear.pub | ssh dietpi@ip_address "cat > dropbear.pub"
ssh dietpi@ip_address
mkdir .ssh
cat dropbear.pub>~/.ssh/authorized_keys

Apply permissions

sudo chmod 700 /home/dietpi/.ssh
sudo chmod 600 /home/dietpi/.ssh/authorized_keys
sudo chown dietpi:dietpi /home/dietpi/.ssh/authorized_keys

Restart service

sudo systemctl restart dropbear.service

Joulinar · 1 February 2023 21:05

Just for understanding, you are getting a Permission denied for both, key as well as password authentication?

Trimble-tech · 1 February 2023 21:11

No, I am getting into the SSH session fine using passwords. My issue is that Dropbear is not utilizing the keys after importing them.

trendy · 2 February 2023 06:10

How do you run the client to connect to dietpi?
ssh -i ~/.ssh/dropbear.key -vvv dietpi@address

Trimble-tech · 6 February 2023 16:50

Hi, sorry for the late reply. I traced my steps back and found two things that were causing an issue.

My permissions were applied in the wrong order: like Joulinar pointed out, I needed to apply chmod on the folder, then the file, and then chown.

sudo chmod 700 /home/dietpi/.ssh
sudo chmod 600 /home/dietpi/.ssh/authorized_keys
sudo chown dietpi:dietpi /home/dietpi/.ssh/authorized_keys

My ssh client is requiring that I identify the key name manually for this Dropbear server.

If I don’t specify the key manually the connection is not established; I need to use this to connect:

ssh -i ~/.ssh/dropbear dietpi@ip_address

When I would like to enter this:

ssh dietpi@ip_address

I have a couple of systems on my network and this would help in case I forget which key is on what system. I suppose I can set a bash alias tied to the IP address to change the SSH command, but that feels improper. Looking into it, I ran this to get logs:

ssh ---vvv dietpi@ip_address

That indicated the SSH client is using id_rsa by default, but that key is for a different system. When trying keys, it doesn’t try the correct key (dropbear) despite it being in ~/.ssh with the others. Permissions are identical among all keys. ls -l ~/.ssh indicates this:

-rw-r--r-- 1 chris chris  568 Feb  6 11:09 dropbear.pub
-rw------- 1 chris chris 2655 Jan 25 14:59 github-maverick
-rw-r--r-- 1 chris chris  568 Jan 25 14:59 github-maverick.pub
-rw------- 1 chris chris 2602 Nov  8 23:23 id_rsa
-rw-r--r-- 1 chris chris  568 Nov  8 23:23 id_rsa.pub
-rw-r--r-- 1 chris chris  444 Feb  3 21:54 known_hosts
-rw-r--r-- 1 chris chris  444 Feb  1 21:06 known_hosts.old

Thank you all for the help so far; this is really good progress.

Trimble-tech · 7 February 2023 16:18

I figured out how to get my SSH key to be used automatically; I’m using an OpenSSH client and (as mentioned) the Dropbear server on my Pi 4. In addition to the steps mentioned, I needed to create an SSH config file on my client (the PC) to tell it to use the key when it connects to Dropbear on the Pi. In ~/.ssh/config, I entered the following:

Host ip_address
IdentityFile ~/.ssh/dropbear
Port 22

“ip_address” is the address of the server
“IdentityFile” points to your key, theoretically it can be anywhere but ~/.ssh is most common.
I optionally added “Port 22” to specify the port for SSH connection. This is default, but if I ever change it I can change it there too so “-p” is not needed for ssh.

In total, the steps I followed for SSH to work from OpenSSH client → Dropbear server are:

Create key: ssh-keygen
Move key to server: ssh dietpi@ip_address "mkdir -p ~/.ssh; tee -a ~/.ssh/authorized_keys" < dropbear.pub
Set the file permissions: ssh dietpi@ip_address "sudo chmod 700 ~/.ssh; sudo chmod 600 ~/.ssh/authorized_keys; sudo chown dietpi:dietpi ~/.ssh/authorized_keys"
Create a config file on client to utilize correct key: echo "Host ip_address">>~/.ssh/config && echo "IdentityFile ~/.ssh/dropbear">>~/.ssh/config && echo "Port 22">>~/.ssh/config
Login to ssh normally: ssh dietpi@ip_address

It is good that this works well; thanks to those pointing me in the right direction. In the meantime I’ll write a script to create & import keys for both OpenSSH and Dropbear servers, so I don’t need to do it manually every time. I put a GitHub link to it when I’m done (if forum rules allow, I think they do after reading) .

Edit: I made the script; it can now create + import keys from an OpenSSH client to both OpenSSH and Dropbear servers. In Dropbear’s case, it automates the steps mentioned here with simple prompts for things like port customization or key names. You can find it on my GitHub page: GitHub - Trimble-tech/SSH-Key-Builder: Builds a new key and imports it to your server.

Qlumzy · 13 February 2023 15:52

I should’ve checked the forum for solution. I went elsewhere and wasted for more than a couple of hours.

Thank you all very much.

Qlumzy · 13 February 2023 16:20

Yes, it’s already working. However, there’s still a question to clarify. There isn’t a need to place the authorized_keys file into the /etc/dropbear directory. Instead, I guess when SSH connects to the user@server, the dropbear SSH will retrieve the public key from the <user-home-directory>/.ssh.

Am I right? Thanks.

Trimble-tech · 13 February 2023 16:47

You are right; in short Dropbear uses <user-home-directory>/.ssh. but OpenWRT uses /etc/dropbear. Keep reading for the full explanation.

OpenWRT, one of the main users to Dropbear, uses /etc/dropbear for the authorized_keys file since it modified their build upstream to specifically use this folder. This change is do to most OpenWRT being single user (root). You can find a little clearer info here about OpenWRT, as I’m not too familiar myself: OpenWRT Forum: Is OpenWRT single User?

With this in mind, the rest of the Dropbear world uses <user-home-directory>/.ssh. Doing so follows OpenSSH norms and improves permissions as only the user in question should be able to see/use the files.

Now, an issue complicating things is that OpenSSH’s ssh-copy-id was built to use /etc/dropbear, as OpenWRT has a strong influence. If you copy a key with that tool, it will not work here. MichaIng tried changing that, but the openssh-portable project seems to be dragging their feet (‘openssh-portable’: GitHub #250).

So, instead of the conventional tools the key needs to be moved and configured manually.