dropbear ssh server won't let me connect

Question

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 [email protected]
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: [email protected]
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.

Answer 1

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.

Answer 2

I just came across this question while looking for reasons why connecting via dropbear to my server stopped working all of a sudden (has been working for months but only occasionally used every couple of weeks).

the solution/explanation i finally found was in the message debug1: send_pubkey_test: no mutual signature algorithm with increased verbosity on my clients ssh connection attempt which led me to a bitbucket troubleshooting article.

that article mentions The RSA algorithm is being quickly deprecated across operating systems and SSH clients due to various security vulnerabilities[...] as a cause and lists as possible workarounds either:

• adding PubkeyAcceptedKeyTypes +ssh-rsa to the clients cfg-file (only use this as a temporary workaround as it is potentionally insecure!)

• use ECDSA or ED25519 algorithm/keys. now with the dropbear version present on my system i could only use ECDSA as ED25519 gave me unknown algorithm errors on dropbears side.

Hope this helps someone stumbling over this question as I did even tough it is probably not a solution to the original question, pls. forgive.

Answer 3

man dropbearkeys:

NOTES
       The program dropbearconvert(1) can be used to convert between  Dropbear
       and OpenSSH key formats.

       Dropbear does not support encrypted keys.

EXAMPLE
       generate a host-key:
        # dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key

       extract a public key suitable for authorized_keys from private key:
        # dropbearkey -y -f id_rsa | grep "^ssh-rsa " >> authorized_keys

Answer 4

authorized_keys is a file, not a directory.

An example authorized_keys file:

    # Comments allowed at start of line
    ssh-rsa AAAAB3Nza...LiPk== [email protected]
    from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
    AAAAB2...19Q== [email protected]

http://man.he.net/man5/authorized_keys

Also the .ssh/ and all files in it must be owned and readable only by the user, in this case root.

Answer 5

Some pointers that may help you get connected using PKI with Dropbear, this tested a container based on Alpine Linux 3.12 packages, connecting from an OpenSSH client.

1. The user needs a shell.
2. The user does not need a login password.
3. The user's ~ must not be group/world writable (i.e. chmod 755 it, at least; you ought to be using 700 for home directories).
4. The user's ~/.ssh and ~/.ssh/authorized_keys must be owner-accessible only (e.g. 700 on the directory and 600 on the file).
5. There must be a writable /tmp directory
6. The authorized_keys entries are in the same format as used by OpenSSH.

I'm making containers using cherry-picked files from alpine packages; I have a ~2MB image that I can ssh into as long as all of the above requirements are met.

Answer 6

You need to create ssh key using dropbearkey tool. RSA_KEYFILE=/etc/dropbear/dropbear_rsa_host_key DSS_KEYFILE=/etc/dropbear/dropbear_dss_host_key

dropbearkey -t dss -f $DSS_KEYFILE

dropbearkey -t rsa -f $RSA_KEYFILE

Then restart the dropbear daemon. Then try to connect, it should work.

Answer 7

I stumbled upon this in particular on Dropbear when using authorized_keys restrictions. I didn't quote the command= restriction, thinking it was not needed when it didn't contain any spaces:

# Bad:
command=/usr/bin/cryptroot-unlock,no-port-forwarding,... ssh-rsa AAAAB3...

# Good:
command="/usr/bin/cryptroot-unlock",no-port-forwarding,... ssh-rsa AAAAB3...

The symptom was the same, just resulting in:

debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

But after adding the quotes, it worked!