It might fail with missing ciphers from the server (on a Raspberry Pi / OpenHabian) or with no message at all other then ‘Authentication failed’ on a Odroid with the latest SNAPSHOT of Openhab2.0.
Took me some time to figure out you need the bouncycastle library (bcprov-ext-jdk15on-155.jar) in the addons directory to make it work!
How connect to it without password, where I must put my id_rsa file?
You need to add public key (most likely .ssh/id_rsa.pub) to authorized keys in Karaf. You can edit ${OPENHAB_HOME}/userdata/etc/keys.properties. This is flat property file where key is username and value is public key used for authentication. Public key must be without perfix (ssh-rsa) and comment at the end, just one long string. After comma you need to assign group, so whole line looks like this openhab=sshkey,_g_:admingroup.
Thanks, it’s work for me on Raspi3. I’m added line to
/var/lib/openhab2/etc/keys.properties
was something changed during the last days ? In the past I was able to enter karaf console using
pi@KGTec1Openhab2Server:~$ ssh -p 8101 openhab@localhost
this doesnt work anymore:
pi@KGTec1Openhab2Server:~$ ssh -p 8101 openhab@localhost
Unable to negotiate with 127.0.0.1 port 8101: no matching host key type found. Their offer: ssh-dss
pi@KGTec1Openhab2Server:~$
openhab.log gives me this:
2017-01-20 14:40:30.183 [WARN ] [he.sshd.server.session.ServerSession] - Exception caught
java.lang.IllegalStateException: Unable to negotiate key exchange for server host key algorithms (client: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 / server: ssh-dss)
at org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:184)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_121]
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[61:org.apache.sshd.core:0.14.0]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_121]
at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)[:1.8.0_121]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implRead(UnixAsynchronousSocketChannelImpl.java:553)[:1.8.0_121]
at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:276)[:1.8.0_121]
at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:297)[:1.8.0_121]
at java.nio.channels.AsynchronousSocketChannel.read(AsynchronousSocketChannel.java:420)[:1.8.0_121]
at org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:170)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:186)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_121]
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[61:org.apache.sshd.core:0.14.0]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_121]
at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)[:1.8.0_121]
at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implRead(UnixAsynchronousSocketChannelImpl.java:553)[:1.8.0_121]
at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:276)[:1.8.0_121]
at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:297)[:1.8.0_121]
at java.nio.channels.AsynchronousSocketChannel.read(AsynchronousSocketChannel.java:420)[:1.8.0_121]
at org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:170)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:135)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:120)[61:org.apache.sshd.core:0.14.0]
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_121]
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[61:org.apache.sshd.core:0.14.0]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_121]
at sun.nio.ch.Invoker$2.run(Invoker.java:218)[:1.8.0_121]
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
I did the following upgrades with apt, it was still working after the 16th, but no more today:
Start-Date: 2017-01-16 15:38:40
Commandline: apt-get autoremove
Remove: linux-headers-4.4.0-53-generic:amd64 (4.4.0-53.74), linux-headers-4.4.0-53:amd64 (4.4.0-53.74), linux-image-4.4.0-53-generic:amd64 (4.4.0-53.74), linux-image-extra-4.4.0-53-generic:amd64 (4.4.0-53.74)
End-Date: 2017-01-16 15:44:11
Start-Date: 2017-01-20 09:40:53
Commandline: apt-get upgrade
Upgrade: libdbus-1-3:amd64 (1.10.6-1ubuntu3.1, 1.10.6-1ubuntu3.3), uuid-runtime:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), libfdisk1:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), dbus:amd64 (1.10.6-1ubuntu3.1, 1.10.6-1ubuntu3.3), libmount1:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), util-linux:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), mount:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), apport:amd64 (2.20.1-0ubuntu2.4, 2.20.1-0ubuntu2.5), libblkid1:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), python3-apport:amd64 (2.20.1-0ubuntu2.4, 2.20.1-0ubuntu2.5), libuuid1:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), oracle-java8-set-default:amd64 (8u111+8u111arm-1~webupd8~0, 8u121-1~webupd8~0), libsmartcols1:amd64 (2.27.1-6ubuntu3.1, 2.27.1-6ubuntu3.2), oracle-java8-installer:amd64 (8u111+8u111arm-1~webupd8~0, 8u121-1~webupd8~0), bsdutils:amd64 (1:2.27.1-6ubuntu3.1, 1:2.27.1-6ubuntu3.2), openhab2:amd64 (2.0.0~20170115182648-1, 2.0.0~20170120042546-1), python3-problem-report:amd64 (2.20.1-0ubuntu2.4, 2.20.1-0ubuntu2.5)
End-Date: 2017-01-20 09:48:15
My initial suspect was a change to openssh default settings, but it seems there was no change to it recently ? anyone else having this issue as well or any clue how to fix this ?
It’s no pi, although the user name might suggest it is… it’s a VM running Ubuntu:
root@KGTec1Openhab2Server:/var/log/apt# uname -a
Linux KGTec1Openhab2Server 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linuxcheck this out:
Ubuntu + updates = new version of OpenSSH = disables ssh-dss on the client side
Quick Fix:
ssh -oHostKeyAlgorithms=+ssh-dss -p 8101 openhab@localhost
This might be completely, utterly unrelated, so don’t give it any credibility without careful research, but here is one recent change.
thanks, that helped !
I also had to delete the old RSA key using
ssh-keygen -f "/home/pi/.ssh/known_hosts" -R [localhost]:8101
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:
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.
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
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