I’m running openHAB 2.5 M5 on a Raspberry Pi 3B+ running openHABian Buster.
Since upgrading from 2.5 M4 to M5 failed (maybe because ZRAM is active), I manually deleted openHAB:
$ sudo service zram-config stop
$ sudo apt purge openhab2
I then reinstalled openHAB again through openhabian-config, while first selecting the testing repository (milestone builds).
Now I have the following nuisance. Whenever I want to access the Karaf console (through openhab-cli console), I have to provide a password.
Is there a way to configure my environment so the openhabian user could again log in to the Karaf console on localhost without having to request a password?
Well, you purged openHAB which means the contents of /var/lib/openhab2/etc got deleted. Then you reinstalled which replaced the contents of that folder with the defaults. Did you re-add your public key to /var/lib/openhab2/etc/keys.properties?
Does this mean I have to generate an SSH key for the openhabian user and add the public key to /var/lib/openhab2/etc/keys.properties? The approch depicted in the following post does not work, I still have to provide the password for openhab:
Logging in to the Karaf console is something you have to configure. By default it only supports password based authentication.
To not have your password requested, you must configure SSH certificates.
If you can ssh to your RPi then you already have SSH certificates. They are located in ~/.ssh.
In order to log into the Karaf console using an SSH certificate, you must give the Karaf console a copy of the public key part of the certificate (~/.ssh/id_rsa.pub most likely). You do this by editing keys.properties.
Correct, because keys.properties by default is not configured to allow log in with SSH certificates. So you need to add a line for the openhab user and supply the public key on that line.
If you can log into your host using SSH certificated than you already have keys generated. You just need to add the ones you already have to keys.properties.
Those instructions work for me. I just redid it to make sure on both OH 2.5 M5 and 2.5 snapshot #1759. There must be something wrong with how you are doing it or something different about your setup.
I routinely log onto my RPi with ssh from any other computer, but all I have configured is that I can log in without password from specific accounts external to the RPi. Those have an entry in ~openhabian/.ssh/authorized_keys with keys generated on those remote accounts.
But I never did anything to generate a key pair for the openhabian user. So I must conclude that this is some nonstandard thing that the openhabian installer takes care of during the first-time installation.
When I generate the key pair for the openhabian user and have it stored in ~/.ssh/ then the only files I see in ~/.ssh/ are:
~/.ssh/id_rsa - the private key of the openhabian user (generated by running ssh-keygen)
~/.ssh/id_rsa.pub - the public key of the openhabian user (needed by Karaf in ~openhab/etc/keys.properties) (generated by running ssh-keygen)
~/.ssh/known_hosts - list of known (trusted) ssh remote hosts
~/.ssh/authorized_keys - list of trusted keys that can log in without providing a password
And in a default OpenHABian installation, up until Milestone 5 the command openhab-cli console logged you in without requesting a password. Milestone 5 now prompts for a password.
This isn’t unique to openHABian or even the apt/yum repositories.
Running $OPENHAB_HOME/runtime/bin/client would log you into the console without a prompt for a password if you were running a default configuration (most people would be I assume). So this looks like a change/regression in the milestone.
$ $OPENHAB_HOME/runtime/bin/client
Logging in as openhab
Password:
and:
$OPENHAB_HOME/runtime/bin/client -k ~/.ssh/id_rsa
Logging in as openhab
Password:
It appears that with OH 2.5 M5 something changed with respect to either certificate handling or ssh with the Karaf upgrade.
Just to make sure I’m correctly understanding how it is supposed to work:
From the openhabian account, generate a private and public key with the ssh-keygen tool. By default, a key pair will be generated in ~/.ssh/ with a default name id_rsa and id_rsa.pub (you can choose a different encryption scheme than rsa, the filename will then reflect this). Note that by using this naming scheme, you shouldn’t have to explicitly provide the key file to ssh.
Copy the public key to $OPENHAB_HOME/etc/keys.properties as in:
Now you should be able to access the Karaf console from the openhabian user account without providing a password… which sadly no longer works as of OH2.5 M5.
The only nonstandard packages I’m running are zram (installed through openhabian-config) and fail2ban. There’s also an nginx reverse proxy running, but as far as I remember, that was also installed through openhabian-config.
For line 2, make sure that you only copied the key part of id_rsa.pub, not the “ssh-rsa” at the beginning and <username>@<server> at the end. Make sure the spaces are also excluded. Only the random string that makes up the public key should be in PUBLIC_KEY_GOES_HERE. A stray space or any other information can render the key unusable.
fail2ban, nginx, etc. would not have anything to do with this. Either there is a regression/change in the Karaf Console or something wrong with your keys.properties I think. I just in the past couple days set up my keys.properties on two different openHAB instances successfully and both are running Karaf 4.2.7. On is installed through openHABian and the other is running in Docker.
I don’t think this is specifically related to changes in Karaf, I’ve just run a standalone instance of Karaf 4.2.7 and can access the console using the client executable without a default password fine. There must be some other change in the milestone causing it.
Found the cause, a change in Karaf 4.2.7 has meant that encrypting passwords always prompts for password entry. You can test this by installing a standalone version of Karaf, and editing the following line in apache-karaf-4.2.*/etc/org.apache.karaf.jaas.cfg
encryption.enabled = true
In Karaf 4.2.6 I am able to login, however in Karaf 4.2.7 it prompts for a password. openHAB’s default is to set this variable to true (${OPENHAB_USERDATA}/etc/org.apache.karaf.jaas.cfg), hence seeing the issue now.
However, KARAF-5217 implies that should have been in intended from a while back. @Kai wdyt? Is it worth commenting on the issue or making a new one? Seems like a regression for a default password.
