Linux Guy's - Why isn't this working? .SSH Auth keys for Pi


I want to create a scene in Vera that when run reboots my Raspberry Pi.

On Vera in Putty I have run these commands:

a) Generate SSH key

dropbearkey -t rsa -f ~/.ssh/id_dss

b) View SSH public key

dropbearkey -y -f ~/.ssh/id_dss

Which then displays me the key.

And on Vera now I can see this folder /.ssh and it contains the id_dss file.

Then on Vera in Putty again, I ran this command to copy the key over to the PI:

cat ~/.ssh/id_dss | ssh pi@ 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

I was prompted for the Pi password and now on the Pi I can see this new folder:

/home/pi/.ssh and in there is a file called authorized_keys

However on Vera in Putty if I then run this command:

ssh pi@

I am still prompted for a password, I expected for it not to prompt me for a password now.

And this is what LUA code I planned to have in my Vera scene.

os.execute("ssh pi@ sudo reboot")

Any ideas why it didn’t work for the auth keys ?

Also looking on the Vera unit there is a file in the .ssh directory called: known_hosts

If I look in this file it contains this: ecdsa-sha2-nistp256 (Then a long string of characters).

Looking on the Pi in its .ssh directory I don’t see a known_hosts file only the authorized_keys file my command generated earlier.

Since you’re not using the Vera’s native (system) keys from /etc/dropbear, you have to specify the key on your command line: ssh -i ~/.ssh/id_dss pi@ whoami

Also make sure your ~pi/.ssh/authorized_keys is not world-accessible and is owned by pi.

Edit: also, it’s a bit odd that you named your key file id_dss but you had it create an RSA key. I don’t think that’s going to matter at all, but it could be misleading in future if some occasion comes up where you need to be using the correct key type.

Edit 2: and as I stare more at what you’ve done, when you appended the public key to the pi’s authorized_keys file, you appended two additional lines from the output of dropbearkey that should not have gone along for the ride. Go edit that file and remove the lines “Public key portion is:” and “Fingerprint:”. You only want the line that starts “ssh-rsa” to be in there.

Edit 3: agggh, no, it’s even worse than that… where you did this:

cat ~/.ssh/id_dss | ssh pi@ 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

You should have done:

dropbearkey -y -f ~/.ssh/id_dss | grep -F ssh-rsa | ssh pi@ 'cat >>~/.ssh/authorized_keys`

You copied the private key and everything into authorized_hosts, but that’s not what’s needed there. You need the public key (which isn’t even exposed in id_dss without using dropbearkey on it).

I got those commands off the forum some place, I used them before to control the VPN client on my router see here.

I did actually try this from the test LUA area of Vera:

os.execute("ssh -i ~/.ssh/id_dss pi@ sudo reboot")

But it didn’t seem to work.

If I run it in Putty on Vera instead it prompts me for a password of the Pi

ssh -i ~/.ssh/id_dss pi@ sudo reboot

If I instead run your command it still prompts me for a password:

ssh -i ~/.ssh/id_dss pi@ whoami



I messed it up then, I can just delete the authorized_keys file on the Pi and run this command:

dropbearkey -y -f ~/.ssh/id_dss | grep -F ssh-rsa | ssh pi@ 'cat >>~/.ssh/authorized_keys`

OK, so let’s regroup here…

First, on the Pi, you need to remove everything from the Vera that you’ve put into authorized_keys so far. You copied binary data into it. Just delete it if there’s nothing else in there you may have needed (no other systems’ keys that connect to that system), otherwise, you’ll need to edit.

Then, on the Vera:

  1. Run this to copy the (Vera) system public key to the Pi:
    dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key | grep -F ssh-rsa | ssh pi@ 'mkdir -p ~/.ssh ; cat >>~/.ssh/authorized_keys'

Then, over on the Pi:

  1. chown -R pi:pi ~pi/.ssh/
  2. chmod 640 ~pi/.ssh/authorized_keys
  3. chmod 700 ~pi/.ssh

Then, back on the Vera, you should be able to: ssh pi@ 'ls -l' (or whatever command) without password.

There is nothing else in there the authorized_keys file didn’t exist before.

If I delete the existing id_dss file from Vera it will break my Virtual switch in Vera that turns ON / OFF the VPN client on my router.

Can I leave it there and use the system public key ?

Perhaps I did it incorrectly for the router as well then previously.

OK. Keep your existing key. But let’s make sure we know what it is. If you do this:

dropbearkey -y -f ~/.ssh/id_dss

Does it show “ssh-rsa” on the second line of output, or “ssh-dss”?

It says:

Public key portion is:

OK, good, then here we go…

On the Vera:

dropbearkey -y -f ~/.ssh/id_dss | grep -F ssh-rsa | ssh pi@ 'cat >>~/.ssh/authorized_keys'


Then, over on the Pi:

  1. chown -R pi:pi ~pi/.ssh/
  2. chmod 640 ~pi/.ssh/authorized_keys
  3. chmod 700 ~pi/.ssh

Then, back on the Vera, you should be able to: ssh pi@ 'ls -l' (or whatever command) without password.

OK I’ve done all that but the last command running on the Vera

ssh pi@ 'ls -l'

Its still prompting for the Pi’s password.

Guess that means it didn’t work.

OK. What’s the contents of the authorized_keys file on the Pi? (it’s a public key so no problem posting it here)
Wait stop…

Sorry, the command should be: ssh -i ~/.ssh/id_dss pi@ 'ls -l'

1 Like

This command works on the Vera terminal

ssh -i ~/.ssh/id_dss pi@ 'ls -l'
1 Like

That’s the one. Sorry about that. Need to specify the key. We could have used the system key anyway and left your id_dss key out of it entirely. Just do this:

dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key | grep -F ssh-rsa | ssh pi@ 'cat >>~/.ssh/authorized_keys'

THEN you should be able to plain vanilla ssh pi@ 'ls -l'

1 Like

Thanks Patrick its working now.

This in the Vera LUA test area just rebooted the Pi !

os.execute("ssh -i ~/.ssh/id_dss pi@ sudo reboot")
1 Like

You can also do it the other way around. For Pi to Ezlo. The instructions for the Pi are here

Then on the Ezlo copy the ~/.ssh/authorized _keys to /etc/dropbear

Cheers Rene

1 Like


I searched Google for several hours this morning but got no where.

The Java process is HA-Bridge. I don’t know where to configure its min/start or max or what values to use.

I am currently rebooting the Pi automatically every evening at 3am via a Vera scene.


Well, I can’t answer for its requirements, but wherever it is started up (sysvinit/init.d? systemd?) it probably uses the java command followed by the name of the JAR file. The -Xms option to the java command sets the starting memory allocation, and the -Xmx sets the maximum. So you could supply -Xms256M -Xmx384M for example, and it would start up with 256M of RAM (thus that is its minimum RAM requirement) and top out at 384M (it will not request more RAM than this from the system and try to work within what it is allowed). If the author doesn’t provide guidance, you may need to experiment. The app will likely crash with an obvious memory exception if the upper limit is too low, but if you don’t set an upper limit, sky’s the limit (Java will happily exhaust system RAM and crash the system).

1 Like

“I also note you have a Java process running. Java’s runtime allocates but never frees memory from the system. It will allocate memory from its configured min/start (-Xms) to its configured max (-Xmx) linearly; it will never return unused memory to the system. You may need to periodically restart the java process to reduce overall system memory use (ideally, of course, you would find a happy setting for max that works for your other system process and the total amount of system RAM, so that java hitting its limit doesn’t cause paging (swap) or system failure).”

Moved us other here, so we are not spamming his VeraFlux thread.

The “habridge.service” file located in /home/pi/habridge folder, that launches HA-Bridge on my Pi is this:

Description=HA Bridge

ExecStart=/usr/bin/java -jar -Dconfig.file=/home/pi/habridge/data/habridge.config /home/pi/habridge/ha-bridge-5.3.1RC1.jar


So now I have remote access to the Pi from Vera, presumably I could send a command from Vera to periodically restart the HA-Bridge service.

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules