To me this indeed looks related, as I didnt do any changes to openssh… Though I didnt do any further research 
In any case, there has been no official release of openHAB 2 yet, so even if the linked PR is related it would not have been a breaking change in the usual sense. If it is related, then it’s easy enough to instruct testers how to adapt to the official release. Interested to hear the final word.
I believe that it is related.
I also believe (I may be wrong) that we will face another bigger problem soon…
As soon as people’s systems start to upgrade openSSH to versions > 7.0 where the ssh-dss (DSA) public key algorithm will be disabled by default from the client, they won’t be able to login into Karaf console.
References:
http://www.openssh.com/legacy.html
In my system (Debian Jessie), I still run openSSH 6.7 without any problems to access the console.
root@host:~# ssh -V
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
Maybe a new PR is needed in order to change the way (migrate from DSA to RSA) that the server key is generated.
It might make sense to alert @Kai to this subject, in case it could in any way impact release building activity.
Also:
1 Like
Maybe the best (safest!) solution for now is to roll back to “simple” keys?
Switching back to simple keys (Karaf internal) from PEM (OpenSSH format) would be the safest/fastest option… (just an opinion)
Note: I made it sound too harsh when I wrote: “they won’t be able to login into Karaf console”… they will get that error message (no matching host key type found. Their offer: ssh-dss) and they will be able to apply the workaround (-oHostKeyAlgorithms=+ssh-dss)
What I don’t understand is: why this problem exists since from what I saw on github, @ThomDietrich when he switched from simple to openSSH the keys with PR #384 is generating correctly RSA keys (not DSA keys).
Maybe a crypto specialist like @rlkoshak can shed some more light into this
I believe you are talking about this? Yes, I am doing that but I’m not certain what is auto-generated on the first connection attempt if no manually created key is available…
Yup… I was referring to exactly that (openssl genrsa -out /var/lib/openhab2/etc/host.key 4096)
You are using correctly RSA algorithm.
I am also not sure what is going on (I am not an expert on crypto 
)
Crypto yes, openSSL’s use of crypto, not so much.
I muddle around with readmes and tutorials when doing this sort of thing like everyone else.
2 Likes
Another work around was to add to the below to your ssh_config file
This goes under " Host * "
HostKeyAlgorithms=+ssh-dss
Then you can login as well with the normal ssh openhab@localhost -p 8101
1 Like
The change to openHAB causing the described behavior (and a few other minor differences) was reverted this afternoon. So whoever is reading here: Everything should be back to normal with the next upgrade and (more importantly) with openHAB 2.0 final.
Best Regards! Thomas
Hi, how to restart JDBC Maria DB connection using karaf console?
I edit ‘items’ file too often, and connection seems to established twice, in charts i see double values of all items.
Thank you.
post your .persist file and jdbc.cfg to check them first. Maybe you are double persisting your items.
The Karaf console commands that you are looking for are:
feature:stop openhab-persistence-jdbc-mariadb
feature:start openhab-persistence-jdbc-mariadb
Hi all.
On my system it seems that every restart of openhab makes the keys used by the karaf console regenerate, so every time I’ve restarted it I need to do a “ssh-keygen -f “/home/malmgren/.ssh/known_hosts” -R [localhost]:8101” before being able to connect to the console. Is this only me?
It might be happening when process running karaf do not have access rights to write into etc directory. Please check who owns etc/host.key file (if exists) and etc directory and if its writeable from karaf process owner.
1 Like
Most probably here: /var/lib/openhab2/etc/host.key
Nope, both directory and file are owned and writeable by openhab, which is the owner of the karaf process. The host.key is empty though, I guess it should contain something?
I also must reset the SSH keys file on my machine after restarting OH2, though the ownership and permissions on the file look right, the file cannot be written to. Should the hosts file be owned by OpenHAB or by the logged in user?
Yes, it should contain key contents. Please set log for org.apache.sshd to DEBUG and try again.
It should be owned by karaf process. User who is authenticated gets karaf process access rights. This means that if you run OpenHab as a root someone who is authenticated to access karaf/openhab shell can execute commands as a root user (ie. exec rm -rf /).