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