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

cw-kid · November 2, 2020, 8:27pm

Hi

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@192.168.1.101 '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@192.168.1.101

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@192.168.1.101 sudo reboot")

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

cw-kid · November 2, 2020, 8:44pm

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:

192.168.1.101 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.

rigpapa · November 2, 2020, 10:54pm

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@192.168.1.101 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@192.168.1.101 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

You should have done:

dropbearkey -y -f ~/.ssh/id_dss | grep -F ssh-rsa | ssh pi@192.168.1.101 '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).

cw-kid · November 2, 2020, 10:55pm

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@192.168.1.101 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@192.168.1.101 sudo reboot

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

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

Thanks

cw-kid · November 2, 2020, 11:00pm

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@192.168.1.101 'cat >>~/.ssh/authorized_keys`

rigpapa · November 2, 2020, 11:22pm

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:

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@192.168.1.101 'mkdir -p ~/.ssh ; cat >>~/.ssh/authorized_keys'

Then, over on the Pi:

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

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

cw-kid · November 2, 2020, 11:07pm

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.

rigpapa · November 2, 2020, 11:07pm

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”?

cw-kid · November 2, 2020, 11:08pm

It says:

Public key portion is:
ssh-rsa

rigpapa · November 2, 2020, 11:20pm

OK, good, then here we go…

On the Vera:

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

NOTICE TO OTHERS: THE ABOVE ONLY WORKS FOR CW-KID THE WAY HE IS SET UP. IF YOU ARE SETTING UP YOUR OWN FOR THE FIRST TIME, CLICK HERE

Then, over on the Pi:

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

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

cw-kid · November 2, 2020, 11:13pm

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

ssh pi@192.168.1.101 'ls -l'

Its still prompting for the Pi’s password.

Guess that means it didn’t work.

rigpapa · November 2, 2020, 11:15pm

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@192.168.1.101 'ls -l'

cw-kid · November 2, 2020, 11:15pm

This command works on the Vera terminal

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

rigpapa · November 2, 2020, 11:17pm

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@192.168.1.101 'cat >>~/.ssh/authorized_keys'

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

cw-kid · November 2, 2020, 11:17pm

Thanks Patrick its working now.

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

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

reneboer · November 3, 2020, 1:45pm

You can also do it the other way around. For Pi to Ezlo. The instructions for the Pi are here https://www.raspberrypi.org/documentation/remote-access/ssh/passwordless.md

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

Cheers Rene

cw-kid · November 10, 2020, 1:50pm

Hi

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.

Cheers.

rigpapa · November 10, 2020, 1:50pm

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).

cw-kid · November 10, 2020, 1:54pm

“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:

[Unit]
Description=HA Bridge
Wants=network.target
After=network.target

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

[Install]
WantedBy=multi-user.target

cw-kid · November 10, 2020, 1:53pm

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.