5

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.

  • Does the dropbear ssh server/config allow for root login? By default on several ssh servers, root login is disallowed for security. – Kenneth B. Jensen Jan 12 '17 at 2:17
  • I think so, I don't see any config file in opt/etc/dropbear (only the host keys), and the parameter to disallow it is -w (not using it). – Chazy Chaz Jan 12 '17 at 2:31
  • Question edited: followed the steps to convert the ssh key to a dropbear key and nothing (as noted by Ipor Sircer from first answer). – Chazy Chaz Jan 12 '17 at 3:04
  • Found documentation in the github repo (can't report there, issues are not enabled). Question edited again. Same problem yet :( – Chazy Chaz Jan 12 '17 at 17:31
2

authorized_keys is a file, not a directory.

An example authorized_keys file:

    # Comments allowed at start of line
    ssh-rsa AAAAB3Nza...LiPk== user@example.net
    from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
    AAAAB2...19Q== john@example.net

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.

  • 1
    I just fixed that but still no luck :( (see updated question). – Chazy Chaz Jan 12 '17 at 3:10
1

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
  • I did managed to convert the private key, but still no luck :( (see updated question). – Chazy Chaz Jan 12 '17 at 3:09
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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.