Security of Karaf console

Tags: #<Tag:0x00007f832dba7ba8> #<Tag:0x00007f832dba7798> #<Tag:0x00007f832dba74f0>

Has anyone successfully used public/private key authentification for karaf console yet? As far as I understood, this should be a possible option to login (and should be preferred for remote login)

Good question. I’ve only changed the password to have at least some security, which is straight forward. I would also be interested in a public key setup.

  1. Create a key on the connecting client through your usual methods (e.g. ssh-keygen)
  2. Copy the public key into openHAB’s (i.e. in userdata/etc/ or /var/lib/openhab2/etc/)
  • This follows the format [username]=[key],_g_:admingroup
  • Default username is openhab.
  1. Volia! Passwordless login

Tiny little amendment: The file is called Just to make that “find” command line a bit easier :smile:

Right you are, edited the above.

Cool! Thanks.

Really cool feature.
One note: This doesn’t seem to work with my freshly created ed25519 key, but it works correct with my old RSA key.

I tried doing this, but I need a little more instructions to get this working.
Could you give all the necessary commands and some example of the end state?
Is a OpenHAB/system restart required?

Enabling passwordless login for OpenHAB could be a useful addition to OpenhabianPi, don’t you agree, @ThomDietrich ?

No problem, I assume you’re on a Debian variant (openHABian etc):

1. Generate the key

Start by generating the private and public key for the client you use to connect:


This will ask you a set of questions, and output a private and a public key file (by default this is /home/<username>/.ssh/ where <username> is probably openhabian.

2. Copy the public key

Read in the public key string and copy it, for example if you use the command:

cat /home/<username>/.ssh/

You get the output:

ssh-rsa AAAABcdefghAAAA <username>@<server>

copy all of the AAAABcdefghAAAA bit as we’ll use that later.

3. Use the copied key in the Karaf keylist.

Simply edit ${OPENHAB_USERDATA}/etc/ to contain the following line above the _g_\admingroup line:


No need to restart openHAB.

4. Use the ssh client to connect to openHAB console

The command will be:

ssh -p 8101 openhab@localhost

and will not ask for a password. If you’re connecting externally, then replace localhost with the server address.

5. (Optional) use openhab-cli to connect to openHAB console

The command follows the same syntax that Karaf uses:

openhab-cli console -k <privatekey>

where <privatekey> is the private key generated in step 1.


Thank you @Benjy , I was able to get it working now! The most important remark was in Step 3 to put the line above . I also noticed that Openhab logs the logon attempts, confirming that it worked!

2018-02-13 20:27:02.768 [INFO ] [as.modules.audit.LogAuditLoginModule] - Authentication attempt - openhabian
2018-02-13 20:27:02.771 [INFO ] [as.modules.audit.LogAuditLoginModule] - Authentication failed - openhabian
2018-02-13 20:39:00.801 [INFO ] [as.modules.audit.LogAuditLoginModule] - Authentication attempt - openhabian
2018-02-13 20:39:00.891 [INFO ] [as.modules.audit.LogAuditLoginModule] - Authentication succeeded - openhabian
1 Like

Dear all, reading your posts it seems that the process of achieving auto-login to karaf console, without keying the password, is quite easy. But I can’t make it work following the process described above.

Being new to linux and after too many hours testing the process described here, studying similar posts like [SOLVED] Openhab default user password, Launch karaf console on openhab2, Automated execution of Karaf commands, Tutorial: Restart Binding from rule, How to solve Exec binding problems, How to restart bundles automatically (as I also want to execute command/scripts from within a rule) and many many attempts to make it work… I have given up ‘cause it is very frustrating not being able to find what’s wrong.

Just in case it might be of interest: I am using openHAB 3.2 installed on a Synology NAS and I am connecting to it from a Win7 PC with the help of WinSCP (Putty).

This is the process I’m following and its results step by step.

1. Login to Synology as user ‘jmvega’ and create openssh key pair

jmvega@DS918:~/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/services/homes/jmvega/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/services/homes/jmvega/.ssh/id_rsa.
Your public key has been saved in /var/services/homes/jmvega/.ssh/
The key fingerprint is:
SHA256:KkJ01kwKArd/6WDF8zT+Ensd3ZiCK3Azrp7bHpdYYL8 jmvega@DS918
The key's randomart image is:
+---[RSA 2048]----+
|+ o   .          |
| o o *           |
|  o + * =        |
| . + . B + . . + |
|  . + + S + o + .|
| . . + = O = o   |
|  . . o B E .    |
|   . . + *       |
|     .=oo        |

New files ‘id_rsa’ and ‘’ have been created under folder ‘/var/services/homes/jmvega/.ssh/

2. Copy the public key ‘’ to the Karaf keylist in /var/services/homes/openhab/userdata/etc/

Contents of ‘’ is:

ssh-rsa AAAAB4Nzpsnrt1EAAAADAQABAAABAQDApTqnK8/YqaLaoW/uLcHbNSftX1WmYJrcNKHD2KmjU+avHHudBSSjArbI1umO70O3jrN1DcasdkjirgBEto+vV76fUCOf3kwZbLx4r73wZU4jkh43hkljwej435j4kxZawXENM3Fyy6ZkOCZpJOE6qK3DAmabDAVESICpmwewe674fgTIXG1wnxme4mqXy2LzUuvkdv9tr4qHtzZzkoJ9DFuWhOR8Vky8LMv+ooeibJK3XHL6WgJrYlyHhrDiT6/+RzhARpdsWZ2WjvyLdH9/DvG11ZUEP+gyaHU95vhcn6IAhL77sTGgc25FvTzN36Q4giydH/eIclBPHukpGkU7yG3RTLsB jmvega@DS918

File ‘/var/services/homes/openhab/userdata/etc/’ is now modified with a new line that reads as:


_g_\:admingroup = group,admin,manager,viewer,systembundles

3. Use the ssh client to connect to openHAB console

jmvega@DS918:~/.ssh$ ssh -p 8101 openhab@localhost
The authenticity of host '[localhost]:8101 ([]:8101)' can't be established.
RSA key fingerprint is SHA256:/AdRnsXRg6jhgKUhqhTI1FTKRIyvXwoqVuu5Z83k3GqVPI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:8101' (RSA) to the list of known hosts.
Password authentication

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.3.0
                               Release Build

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.


And now a new file name ‘known_hosts’ has been created under folder ‘/var/services/homes/jmvega/.ssh/
However… If I logout and re-login with ‘ssh -p 8101 openhab@localhost’, I am asked again to key the password (habopen). Why??
In order to get a better insight on what’s happening I do a login in verbose mode and this is the result:

openhab> logout
Connection to localhost closed.
jmvega@DS918:~/.ssh$ ssh -v -p 8101 openhab@localhost
OpenSSH_7.4p1, OpenSSL 1.0.2o-fips  27 Mar 2018
debug1: Connecting to localhost [] port 8101.
debug1: Connection established.
debug1: identity file /var/services/homes/jmvega/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory**
debug1: identity file /var/services/homes/jmvega/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /var/services/homes/jmvega/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version SSHD-CORE-1.6.0
debug1: no match: SSHD-CORE-1.6.0
debug1: Authenticating to localhost:8101 as 'openhab'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:/AdRnsXRg6jhgKUhqhTI1FTKRIyvXwoqVuu5Z83k3GqVPI
debug1: Host '[localhost]:8101' is known and matches the RSA host key.
debug1: Found key in /var/services/homes/jmvega/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: keyboard-interactive,password,publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /var/services/homes/jmvega/.ssh/id_rsa
debug1: Authentications that can continue: keyboard-interactive,password,publickey
debug1: Trying private key: /var/services/homes/jmvega/.ssh/id_dsa
debug1: Trying private key: /var/services/homes/jmvega/.ssh/id_ecdsa
debug1: Trying private key: /var/services/homes/jmvega/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password authentication

It attracts my attention the initial lines:
debug1: identity file /var/services/homes/jmvega/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory**

Why does it say “No such file or directory” for “/var/services/homes/jmvega/.ssh/id_rsa”. I can see the file!!
So… is it a matter of permissions?
In order to check if the issue is related to permissions I have assigned RW permissions to user ‘openhab’ over the folder ‘/var/services/homes/jmvega/.ssh/’. I have also deleted file ‘known_hosts’ so it can be recreated again once I login to karaf console (step 3 above). No luck. The result shown in the screen is exactly the same as above. So… I’m stuck.

I will very much appreciate your help to identify what I’m doing wrong.

If using ssh from console, you need either to use a password agent or explicitly hand over the key file.

ssh openhab@localhost -p8101 -i/var/services/homes/jvmega/.ssh/id_rsa

This will work without password only if the key file wasn’t secured when creating the key pair.

You don’t need to delete the known_hosts file, this is to check whether the computer you connect to is the correct one.
Think of a remote machine somewhere else. You’ve logged in successfully. The machine is replaced by another one, but with the same IP (and dns resolves to this IP).
Now, if you try to login, ssh will complain about a potential attack, because the known_hosts file fingerprint does not match any longer. GNU/Linux ssh will not permit to contact such a computer, until you deleted the fingerprint from known_hosts file (ssh-keygen -R the.ip.add.ress && ssh-keygen -R <fqdn>). After deleting the host fingerprint from known_hosts, ssh will prompt the new fingerprint.
If you want a really secure communication, you have to check through another channel (take a look at the real machine…) if the fingerprint matches.

Did you check this thread as well?

Hi Udo,
Thanks a lot for your quick answer and detailed explanation. It not only has helped me to find the solution but also has been a guide to learn a bit more about ssh and permissions.
Your advice is right, I have successfully logged in through the console with

ssh openhab@localhost -p8101 -i/var/services/homes/jvmega/.ssh/id_rsa

It has not being inmmediate because instead of keying the whole command I just copied what you typed. And there is a “small” difference (user is “jmvega” instead of “jvmega) that has taken me several trials to realize. It’s been very positive because I have learnt that no matter that the user has been mistakenly typed in the command line, it does not have any impact at all. In its output ssh complains about it but eventually it does log in. Let me explain the process I followed because it may be of interest to other users.

To ensure I started from scratch, I deleted the key files ‘id_rsa’, ‘’ and ‘known_hosts ‘ (under folder ‘/var/services/homes/jmvega/.ssh/’). I recreated the private and public keys and updated the contents of '/var/services/homes/openhab/userdata/etc/' accordingly . However, login in from console with ‘ssh openhab@localhost -p8101 -i/var/services/homes/jvmega/.ssh/id_rsa’ generated the following output:

Using username &quot;jmvega&quot;.
jmvega@'s password:
jmvega@DS918:~$ ssh openhab@localhost -p8101 -i/var/services/homes/jvmega/.ssh/id_rsa
Warning: Identity file /var/services/homes/jvmega/.ssh/id_rsa not accessible: No such file or directory.
Permissions 0777 for '/var/services/homes/jmvega/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key &quot;/var/services/homes/jmvega/.ssh/id_rsa&quot;: bad permissions
Password authentication

I realized two issues to be fixed:

a) Message ‘Warning: Identity file /var/services/homes/jvmega/.ssh/id_rsa not accessible: No such file or directory.’ => the user is incorrect.

b) Message ‘Permissions 0777 for '/var/services/homes/jmvega/.ssh/id_rsa' are too open…. This private key will be ignored

I first fixed a) and then b) by assigning permissions x0700 (owner only) to folder “.shh” and its contents (I may have changed its permissions previously during my many attempts to make it work).

Now it works as expected with the command line you suggested: ‘ssh openhab@localhost -p8101 -i/var/services/homes/jmvega/.ssh/id_rsa

However, to my surprise, it also works without any reference to the key file, just with ‘ssh -v openhab@localhost -p 8101’:

jmvega@DS918:~$ ssh openhab@localhost -p 8101
                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.3.0
                               Release Build
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.

Executing this command in verbose mode it seems that, in the abscense of a reference to the key file, the ssh command looks for the default key file ( id_rsa ) in the default ssh folder ( .ssh ) of the current user (’jmvega’).

Definitely I have to get some deeper insight on linux (…for which I have just acquired a well known book).

Again… thanks Udo for your guidance :slight_smile:

Thanks for your suggestion and yes, I had also checked your post but did not go very much into it because it also involves executing a command from a rule, which added an additional level of complexity for me (I’m learning as fast as I can but I’m still a novice…).
Now that I have acquired a basic understanding of how ssh works, I’m capable to understand your instructions as this is my next step: to be able to run a coomand line from within a rule.
Again, thanks for your consideration to answer my post.

I hope you will succeed soon.
But you know, I am not a pro, too, I have struggled a while solving the restart within a rule myself.
So that’s why I have initiated this howto.
Hope it helps and let me know what can be improved on it.

I had to remove and do a new docker installation of OH.
Now I cannot get into karaf console that shows up this error warning “remote host identification has changed!”
Something about adding correct host key in /root/.ssh/known_hosts:28
It instructed me to
“ssh-keygen -f “/root/.ssh/known_hosts” -R [localhost]:8101”

which I did but I still cannot get into the karaf console

Known hosts contains keys of machines you connect to. OpenHAB will generate new key when launching a fresh installation.
You can edit known hosts file manually - just remove line 28 in it. It also worth to note that each user (ie root) under linux have own known hosts. If you have a standard user you need to look in his home directory at /home/xyz

I have just gone through this process too. I got it to work and made my own how to post here: