Solved: Passwordless Key-Based SSH Authentication on EZLO

Apps & Remote Access General Discussions
#1

I’ve had to ssh into my vera a lot to debug problems with it. Enough times that I’m getting tired of typing in the password each time.

I know it’s running a repackaged openwrt and dropbear, not openssh. Normally I’d add my pubkey to /root/.ssh/authorized_keys. But that’s not working. I tried /etc/dropbear/authorized_keys and /etc/dropbear/dropbear_authorized_keys as well, and no dice.

group and others peermissions are nulled out. Where can I find out why it’s not authenticating via key?

When I add -vvvvvvv to my client (linux/fedora) I do see reference to “debug1: send_pubkey_test: no mutual signature algorithm”.

I don’t see any config in /etc/dropbear that would indicate what signature algorithms it’s permitting. Maybe it’s compiled in? sheesh, what should I check?

#2

I’m not an expert in any of this, but does any information in this thread help?

#3

Your thread is talking about going the other direction: Connecting from Vera out to another host.

One interesting detail though was creating the SymLink at /.ssh. Pointing at /root/.ssh . That’s not normal on a Linux system. It indicates to me that something is not assigning roots home directory, /root correctly all the time.

#4

Well if you work it out let us know, I am in the same boat using putty, have to enter the password each time.

#5

I figured it out. I think. And the way I fixed it appears unrelated to the symlink dir.
My problem was that modern linux ssh clients (and perhaps putty as well) no longer use ssh-rsa, but I think ssh-rsa is the most secure pubkey type offered by the vera.

In ssh, all hosts have keys. And users can have keys, or pw’s (or both, or other combinations of wackyness). I’m not 100% sure if it’s the vera’s key or my user’s that is obsolete. But I’ve run into this before on old network gear (the only kind I buy). Usually cisco/brocade don’t update the firmware forever, and so to connect to them you have to tell your client to downgrade it’s security and use older protocols that normally it would reject. (Think of how SSL/TLS keeps evolving and eventually browsers don’t connect to old servers any more.)

So to get around this I added this section to my ssh client’s .ssh/config file:

Host vera
  PubkeyAcceptedKeyTypes +ssh-rsa

This is the config file of my SSH Client. You could also add the -o PubkeyAcceptedKeyTypes=ssh-rsa operand when connecting: ssh root@veraiphere -o PubkeyAcceptedKeyTypes=ssh-rsa

After making this change, the key I installed in /etc/dropbear/authorized_keys works as expected.

[myuser@Mylaptop .ssh]$ ssh root@vera -o PubkeyAcceptedKeyTypes=+ssh-rsa -i id_rsa_2022 


BusyBox v1.19.4 (2019-12-04 15:22:44 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.

root@MiOS_50696969:~#

the “-i id_rsa_2022” argument is only there because I’ve decided to start making a new keypair every so often. I checked and the one I have been using for the last decade is ‘smaller’ than what I get by default when generating a fresh one today and that can’t be good.

So now I need to learn how to make my ssh client manage trying multiple keys in order, and alerting me when an old one is used… Great. I needed more to do…

Oh. I also made a symlink in /root/.ssh/ named authorized_keys that points to /etc/dropbear/authorized_keys because ssh clients will commonly try to install their keys in the $HOME/.ssh/authorized_keys. But dropbear only looks in /etc/dropbear/ for the file. So with this link, if I use “ssh-copy-id” in the future to add another key it will ‘just work’

1 Like