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.
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 ?
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:
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).
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.
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! )
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.
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.
Ok - now it looks like with QNAP - I can only ssh with the default ‘admin’ account (How to SSH into your QNAP device - QNAPedia) - 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.
Sure, yes, agreed - I already have it installed on my QNAP (https://www.qnapclub.eu/en/qpkg/585) 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,)
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.
Quick question, when I run the above I receive the following message.
root@MiOS_501001234:/# ssh pi@192.168.1.37
Host '192.168.1.37' 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)
y
ssh: Connection to pi@192.168.1.37:22 exited: Remote closed the connection
Does that sha1 fingerprint mean anything in the grand scheme of things ?
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.
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’
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
Results
No errors
Runtime: 219.9 ms
Code returned: nil
Print output
-----------
Code
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
9
10 execute "ssh -i /etc/dropbear/dropbear_rsa_host_key pi@192.168.1.37 ‘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@192.168.1.37 'ls -l'
total 43312
-rwxr-xr-x 1 pi pi 21631 Sep 2 19:09 bled112_scanner.py
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 ?
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
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 ?