Ssh – dropbear ssh server won’t let me connect

dropbearkey-authenticationlinuxopenwrtssh

I'm trying to gain ssh access to my router. Currently I only have telnet access and I installed dropbear and is running (using opkg on a usb drive connected to the router).

From the beginning, what I did was generate a private key and decrypt it (since dropbear doesn't support this yet) and the public one:

cd .ssh
openssl genrsa -des3 -out id_rsa
openssl rsa -in id_rsa -out id_rsa
ssh-keygen -y -f id_rsa > authorized_keys

I uploaded the public key (authorized_keys) to /root/.ssh. I put the file on a Apache server (in my local computer) and download it on the router using wget (so the downloaded file gets root as owner/group) and then changed the permissions to 0600 (same for the client but with my user).

When I try to access, it gives me a "Permission denied (publickey)" error:

$ ssh -v -i ~/.ssh/id_rsa root@192.168.1.1
OpenSSH_7.4p1, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/chazy/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: no match: dropbear
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o
debug1: Host '192.168.1.1' is known and matches the RSA host key.
debug1: Found key in /home/chazy/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/chazy/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Unless I'm misreading what the documentation (GitHub repo) says:

Server public key auth:

You can use ~/.ssh/authorized_keys in the same way as with OpenSSH,
just put the key entries in that file. They should be of the form:

ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV+ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk/yU99UVv6NWV/5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET/MG8qyskG/2IE2DPNIaJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc=
someone@hostname

You must make sure that ~/.ssh, and the key file, are only writable by
the user. Beware of editors that split the key into multiple lines.

Dropbear supports some options for authorized_keys entries, see the
manpage.

I did everything it says, so I don't know where the problem could be.

The documentation mentions another way:

Client public key auth:

Dropbear can do public key auth as a client, but you will have to
convert OpenSSH style keys to Dropbear format, or use dropbearkey to
create them.

If you have an OpenSSH-style private key ~/.ssh/id_rsa, you need to
do:

dropbearconvert openssh dropbear ~/.ssh/id_rsa ~/.ssh/id_rsa.db
dbclient -i ~/.ssh/id_rsa.db

Dropbear does not support encrypted hostkeys though can connect to
ssh-agent.

So this menas that if I convert the private key to a dropbear private key, I can use the dropbear client to connect to the dropbear server:

dropbearconvert openssh dropbear id_rsa id_rsa.db

I'm going to give this a try and see if it works. But anyways, Server public key auth should work.

Best Answer

Short answer: You are probably running OpenWrt, and you need to put your public key in /etc/dropbear/authorized_keys instead of /root/.ssh/authorized_keys.

Long answer:

The GitHub repo you point to is the one maintained by the dropbear author; it says that ~/.ssh/authorized_keys works, and according to GitHub it has done so at least for 14 years. Looking at the code in svr-authpubkey.c it adds /.ssh/authorized_keys to the "pw_dir".

I, however, had the same problem as you have, and I discovered that the binary provided in OpenWrt 18.06.1 is actually opening /etc/dropbear/authorized_keys. Using that file works for me.

This behavior is documented in the OpenWrt docs.

So how come?

Given that the code above cannot produce that filename on its own (the .ssh is missing) and there is no .ssh symlink anywhere, I ran strings on the binary. That showed that /etc/dropbear/authorized_keys is mentioned explicitly, just before the %s/.ssh/authorized_keys that can be expected from the GitHub code. I conclude that the OpenWrt binary is not compiled from the same sources... and indeed, OpenWrt patches the upstream code with this patch. It changes the file used to /etc/dropbear/authorized_keys if (and only if) the target user is root.

Since you mention opkg, I imagine you are also using OpenWrt, and that this is your problem. I've added an OpenWrt tag to your question.

Related Question