dropbear ssh server won't let me connect
Solution 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.
Solution 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.
Solution 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
Solution 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
.
Related videos on Youtube
Chazy Chaz
Updated on September 18, 2022Comments
-
Chazy Chaz over 1 year
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.
-
Admin over 7 yearsDoes the dropbear ssh server/config allow for root login? By default on several ssh servers, root login is disallowed for security.
-
Admin over 7 yearsI 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). -
Admin over 7 yearsQuestion edited: followed the steps to convert the ssh key to a dropbear key and nothing (as noted by Ipor Sircer from first answer).
-
Admin over 7 yearsFound documentation in the github repo (can't report there, issues are not enabled). Question edited again. Same problem yet :(
-
-
Chazy Chaz over 7 yearsI did managed to convert the private key, but still no luck :( (see updated question).
-
Chazy Chaz over 7 yearsI just fixed that but still no luck :( (see updated question).
-
Admin almost 2 yearsThank you, you saved me!