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'
1 Like
This command works on the Vera terminal
ssh -i ~/.ssh/id_dss pi@192.168.1.101 '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@192.168.1.101 'cat >>~/.ssh/authorized_keys'
THEN you should be able to plain vanilla ssh pi@192.168.1.101 '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@192.168.1.101 sudo reboot")
1 Like
You can also do it the other way around. For Pi to Ezlo. The instructions for the Pi are here Raspberry Pi Documentation - Remote access
Then on the Ezlo copy the ~/.ssh/authorized _keys to /etc/dropbear
Cheers Rene
1 Like
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.
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:
[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
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.
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. 
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@192.168.1.100 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@192.168.1.100 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.
Hi,
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 id_rsa.pub -> ssh_host_rsa_key.pub
-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 ssh_host_dsa_key.pub
-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 ssh_host_rsa_key.pub
[/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:
- A file typically called
known_hosts, which holds the public host keys of other systems that user hasssh’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_keyscontaining 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
.pubsuffix) that are used to access other systems. Probably most common on Linux is just two filesid_rsaandid_rsa_pubthat 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.
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 (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.
Pi? NUC? Jetson Nano?
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.