After reinstalling OH2.5M5 on openHABian I now have to provide credentials for running openhab-cli console

Tags: #<Tag:0x00007f61761885d8> #<Tag:0x00007f61761884e8>

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?

That may be an oversight, Karaf version was updated. Please file an issue on GitHub.

Done:

Thanks. Getting ready to upgrade now.

EDIT: Somebody else said restarting OpenHAB resolved their ssh issue. Have you tried that?

More than once, including rebooting the RPi… to no avail.

1 Like

Verified. I even removed the cache & tmp files but still have the issue.

FYI the password is habopen

I know, I changed the default openhab password on my server through openhabian-config.

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?

So far I never generated any key for my openHAB setup. This key must thus have been generated by the first-time installer (the openhabian installer?).

The only nonblank or non-comment line in /var/lib/openhab2/etc/keys.properties is:

$ cat /var/lib/openhab2/etc/keys.properties | grep -vE '^$|^#'
_g_\:admingroup = group,admin,manager,viewer,systembundles,ssh

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:

Here’s what I get:

[16:49:15] openhabian@openhab:~$ ssh -p 8101 openhab@localhost
Password authentication
Password: 
[16:49:23] openhabian@openhab:~$ openhab-cli console

Logging in as openhab
Password:  
[16:52:00] openhabian@openhab:~$ openhab-cli console -k ~/.ssh/id_rsa

Logging in as openhab
Password:  

Remark: Karaf reports it’s on version 4.2.7.

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.

Same here.

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

I have no clue why it’s not working.

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.

Precisely.

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.

1 Like

Apparently not:

$ $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:

  1. 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.
  2. Copy the public key to $OPENHAB_HOME/etc/keys.properties as in:
openhab=PUBLIC_KEY_GOES_HERE,_g_:admingroup
_g_\:admingroup = group,admin,manager,viewer,systembundles,ssh
  1. 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.

Agreed. Karaf was updated to a newer version.

Upgrade Karaf tooling and openHAB TP to 4.2.7 (#1197) (details / githubweb )

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.

1 Like

Thanks @Benjy. Let us know if there is anything we can test.

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.

1 Like