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

That’s systemd. No limits on Java. Java is not your biggest consumer, though, InfluxDB is; I just noted the potential for two competing potential memory hogs.

I’m not going to respond further here; this thread seems more OT for this topic than where we were. :thinking:

Quite possibly, but its my thread so doesn’t matter.

1 Like

Tried using this command from Vera to restart the HA-Bridge service on the Pi

ssh -i ~/.ssh/id_dss pi@ sudo systemctl restart habridge.service

Which seemed to work, so maybe I can setup a schedule for now.

I then tried this command for the InfluxDB service.

ssh -i ~/.ssh/id_dss pi@ sudo systemctl restart influxd.service

Although InfluxDB is using so much memory and CPU, I am going to have to disable it completely I think.


I’ve just found this particular thread and I’d like to do the same, but in this case connect to my QNAP NAS.

The one concern I have is that looking in my QNAP’s ssh folder, there looks to be a number of rsa files in there already - will doing this cause me any issues ?

QNAP Terminal

/etc/config/ssh] # ls -l
total 24
lrwxrwxrwx 1 admin administrators    9 2015-02-11 21:01 authorized_keys -> /dev/null
lrwxrwxrwx 1 admin administrators   16 2014-11-09 19:11 id_rsa -> ssh_host_rsa_key
lrwxrwxrwx 1 admin administrators   20 2014-11-09 19:11 ->
-rw-r--r-- 1 admin administrators  188 2020-11-30 11:46 sshd_config
-rw-r--r-- 1 admin administrators   17 2020-11-30 11:46 sshd_user_config
-rw------- 1 admin administrators  668 2014-11-09 18:59 ssh_host_dsa_key
-rw-r--r-- 1 admin administrators  605 2014-11-09 18:59
-rw------- 1 admin administrators 1675 2014-11-09 18:59 ssh_host_rsa_key
-rw-r--r-- 1 admin administrators  397 2014-11-09 18:59
[/etc/config/ssh] #

You don’t want to do root login to the QNAP, so those files don’t apply. The commands given above for the RPi should work just fine, you just need to provide the correct username (not pi) and your QNAP’s IP address.

TL;DR: Go for it. Just use the username for your QNAP user (not root, not ever root) instead of pi in the commands above, and of course, replace the IP address shown with that of your QNAP NAS.

The works of it is just this: each user has (or can have) a .ssh subdirectory (normally hidden from ls, but visible by doing ls -a) in the user’s home directory, and you can cd into it. This stores that user’s particular SSH configuration. There are three things you might find in this directory if it exists:

  1. A file typically called known_hosts, which holds the public host keys of other systems that user has ssh'd into. These are kept so that future connections to that host can verify the same public key; you’ll get a warning if you connect to a host you’ve connected to before but the key doesn’t match (i.e. maybe somebody put a different machine at that IP address and is now attempting to scrape usernames and passwords). This isn’t relevant to this discussion except as a mention, so I’ll leave it at that (ignore this file).
  2. A file called authorized_keys containing the public keys of any other users (or systems) that are allowed to connect to this system as this user without a password.
  3. Any number of user key files (public and private in a single file, or separated into two files, one often with no suffix and the other with a .pub suffix) that are used to access other systems. Probably most common on Linux is just two files id_rsa and id_rsa_pub that are created when the user account is created. I won’t go more into this; these files can be ignored (and don’t touch! :slight_smile: )

What we’re doing is we are taking a copy of the public key (only; never move the private key) from the source system (Vera, in this case) and putting it into authorized_keys on the target system in the SSH config of the target user account. Since the Vera typically only uses its system key for establishing remote connections (OpenWrt doesn’t have users other than root, and does not create a separate key for that user), that’s the public key we are going after. So the dropbearkey command in the other post plus the grep that follows extracts the Vera’s host public key. The rest of that command just pushes that public key onto the target user’s authorized_keys file (creating both the directory and file if needed). And the commands after (chown, chmod) just make sure that file permissions on any newly created .ssh directory and authorized_keys file on the target system are locked down correctly – most ssh servers will ignore files that have permissions set too relaxed, for security.

Thanks @rigpapa !!

QQ …

If the QNAP already has an .ssh location, ‘/etc/config/ssh’ how should I update the above to match that ? Or doesn’t it matter ?

That is not a .ssh location, that is /etc/config/ssh, the system’s SSH directory. That’s someplace you don’t want to be, and it should be left undisturbed. You will only be touching a user-specific SSH configuration with those commands, and that’s as it should be.

The directory(ies) called .ssh will only be found in user home directories.

Thanks again @rigpapa

Ok - now it looks like with QNAP - I can only ssh with the default ‘admin’ account ( - unless I want to open and edit as particular file ? (No idea how dangerous that is?)

I’m guessing using ‘admin’ is not ideal…

I’m ultimately looking for a device I can run ‘imagemagick’ on to process some camera images - and as my NAS provides the folder (via a CIFS mount option on Vera) / the qnap seems the idea place to access (plus I have imagemagick installed on their already…

You’d have to find a build of the ImageMagick library compatible with the processor and runtime/libc running on the QNAP. Have you looked into that? I think that may be made of pure unobtainium. Building from source would be your alternative, but then, you’d need a compiler and header files… I just don’t know anything/enough about QNAP to know what’s really available, but I would not surprised if the answer is none of it.

Pi? NUC? Jetson Nano?

Sure, yes, agreed - I already have it installed on my QNAP ( and I’ve been using it for a short while learning bits an pieces. (i’ve just worked out how to take 4 different camera images and build a single grid image - I’m now looking to see if I can do that automatically via a script,) :slight_smile:

Thinking about it, it might be best for me to use an old pi I have laying around…

We could probably figure out how to get you password-less file transfer/shell for the QNAP admin account, but I think that’s a really bad practice, especially given how not secure Vera’s themselves are by nature. Offloading that to another small processor that you can secure better is, I think, a better option.

Agreed, Pi it is.

SMB and imagemagick here I come…

Quick question, when I run the above I receive the following message.

root@MiOS_501001234:/# ssh pi@

Host '' is not in the trusted hosts file.
(ecdsa-sha2-nistp256 fingerprint sha1!! 4d:48:e6:a6:52:29:a6:ee:rs:92:e5:4c:de:f5:d6:2f:7e:49:bc:cf)
Do you want to continue connecting? (y/n)
ssh: Connection to pi@ exited: Remote closed the connection

Does that sha1 fingerprint mean anything in the grand scheme of things ?

Sadly I still get the password prompt … :frowning:

Run the following commands on the two systems as indicated, collect and send all of the output in a PM to me. Don’t worry if there are any error messages, but please include them in the output (just copy-paste everything from the first command to the last line of output from the last in each case).

On the Vera:

dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key
ls -la /etc/dropbear/
ls -la /root/.ssh
cat /root/.ssh/known_hosts
cat /etc/dropbear/authorized_keys

On the pi, logged in as user “pi”:

ls -la ~/.ssh
cat ~/.ssh/authorized_keys
cat ~/.ssh/known_hosts
cat /etc/ssh/sshd_config

For the benefit of others following the thread or reading it later, since we went PM with some potentially sensitive data being exchanged:

@parkerc had created an additional set of keys for the root user, which is not the typical configuration for Vera systems – normally root on Vera just uses the system’s keys in /etc/dropbear. We were able to establish a working connection without password by using the “-i” option on ssh and specifying the path to the system key, and it worked as expected (no password needed). The fix, then, was simply to remove the extra/unneeded redundant set of keys that were getting in the way by removing the /root/.ssh directory.

In principle, there’s nothing wrong with any user, including root, having multiple keys. In fact, this is a good way to isolate access when you are contacting multiple systems – create a different key to be used for each target system, and if the private key for one is accidentally exposed, it would still not be usable to get to the others. But because Vera’s security is pretty weak to begin with, this is extra work with little ROI. If anyone goes this route, you’ll need to use the “-i” option to ssh/scp to select the key to use for that session, and it will surely choose the wrong key if left to its own to decide.

Thanks @rigpapa for all that you’ve done to help…

Everything seems to work at the command line now when specifying the cert/key - however any ideas why I can’t see the output via Lua Test and the ‘print’ command ? The same list request just returns ‘256’

LuaTest 1.7

Lua file: /etc/cmh-ludl/luatest.lua

No errors
Runtime: 207.8 ms
Code returned: nil

Print output

   1   print(os.execute("ssh -i /etc/dropbear/dropbear_rsa_host_key pi@ 'ls -l'"))

I also tried a version with io.popen too, which did not give me anything.

LuaTest 1.7

Lua file: /etc/cmh-ludl/luatest.lua

No errors
Runtime: 219.9 ms
Code returned: nil

Print output

   1   local function execute (command) 
   2       p = io.popen (command) 
   3       local out = p: read "*a" 
   4       p: close() 
   5       print (out) 
   6       print "-----------" 
   7       return out 
   8   end 
  10   execute "ssh -i /etc/dropbear/dropbear_rsa_host_key pi@ ‘ls -l’"

Whereas the same thing at the command line - I get this.

root@MiOS_50102345:~# ssh -i /etc/dropbear/dropbear_rsa_host_key pi@ 'ls -l'
total 43312

-rwxr-xr-x  1 pi pi    21631 Sep  2 19:09
drwxr-xr-x  2 pi pi     4096 May 27  2019 Desktop
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Documents
drwxr-xr-x  5 pi pi     4096 Sep 23 09:27 Downloads
drwxr-xr-x 15 pi pi     4096 Dec  6 12:25 ImageMagick-7.0.10-46
-rw-r--r--  1 pi pi 13764132 Dec  5 21:44 ImageMagick.tar.gz
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 MagPi
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Music
drwxr-xr-x  4 pi pi     4096 Apr 19  2019 oldconffiles
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Pictures
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Public
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 python_games
drwxr-xr-x  2 pi pi     4096 Dec  7 00:04 shared
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Templates
drwxr-xr-x  4 pi pi     4096 Oct  3 09:34 vera-toolchain
drwxr-xr-x  2 pi pi     4096 Oct  9  2018 Videos
drwxr-xr-x  4 pi pi     4096 Aug 28  2019 ZMESerialUpdater
-rw-r--r--  1 pi pi  9513876 Aug 28  2019 ZMESerialUpdater.tgz
-rw-r--r--  1 pi pi 20980722 Jan 24  2019 z-way-3.0.0-rc20_armhf.deb

Is it just a case that the print request returns to quickly ?

Works fine for me this way:

root@MiOS_450xxxxx:~# lua
Lua 5.1.5  Copyright (C) 1994-2012, PUC-Rio (double int32)
> f=io.popen( "ssh -i /etc/dropbear/dropbear_rsa_host_key veralogs@ 'ls -l'" );
> t=f:read("*a");
> f:close()
> =t
total 1820
drwxr-xr-x 2 veralogs veralogs  135168 Dec  7 00:05 450xxxxx
drwxr-xr-x 2 veralogs veralogs 1495040 Dec  7 09:11 500xxxxx
drwxr-xr-x 2 veralogs veralogs  217088 Dec  7 00:05 500xxxxx
drwxr-xr-x 3 veralogs veralogs    4096 Oct  9 10:24 storage


You have curly single quotes around the ls -l in the code you posted. I don’t know if you actually submitted to the shell it that way, or just the way you posted it, but it wouldn’t run if you did. And io.popen() is the correct usage. os.execute() does not return any output, just a status (number).

It must be a Lua Test issue , as doing it just as you did, via the Lua command line worked for me too…

This is the code I want to execute, but I can’t seem to get it to run programmatically (via code running via Vera), yet it works if I type it in directly at the command line

ssh -i /etc/dropbear/dropbear_rsa_host_key pi@ "montage shared/conservatory.jpg shared/cabin.jpg shared/frontroom.jpg shared/kitchen.jpg -tile 2x2 -geometry 1000 shared/assembly3.jpg"


Does anyone have any ideas how I can check/see what’s going wrong when I try and send an ssh command to a remote device via Vera code ? When the same command works when typed directly into the console ?

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules