Karaf SSH console

[Duncan Smith]

Hi All,

Has anyone used Karaf's ssh console lately? I seem to be running into keyex issues.

Environment:

Ubuntu 16.04, Java 1.8.0.171

Googling suggests that my issue is related to the changes introduced by https://bugs.java.com/view_bug.do?bug_id=8184341

Does anyone have a workaround for getting into the console of an running OC instance?

Logs below.

Connection attempt (requires ssh-dss since that seems to be the only algorithm that Karaf supports):

# ssh -p 8101 admin@localhost -oHostKeyAlgorithms=+ssh-dss -v

OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g  1 Mar 2016

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug1: /etc/ssh/ssh_config line 57: Deprecated option "useroaming"

debug1: Connecting to localhost [::1] port 8101.

debug1: connect to address ::1 port 8101: Connection refused

debug1: Connecting to localhost [127.0.0.1] port 8101.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_rsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /root/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

debug1: Remote protocol version 2.0, remote software version SSHD-CORE-0.14.0

debug1: no match: SSHD-CORE-0.14.0

debug1: Authenticating to localhost:8101 as 'admin'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: ecdh-sha2-nistp256

debug1: kex: host key algorithm: ssh-dss

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

Connection closed by 127.0.0.1 port 8101

OC log:

2018-08-16 15:03:08,967 | WARN  | sshd-SshServer[5f703316]-nio2-thread-3 | (AbstractSession:456) - Exception caught

java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size

at sun.security.provider.DSA.checkKey(DSA.java:111)[:1.8.0_171]

at sun.security.provider.DSA.engineInitSign(DSA.java:143)[:1.8.0_171]

at java.security.Signature$Delegate.engineInitSign(Signature.java:1177)[:1.8.0_171]

at java.security.Signature.initSign(Signature.java:530)[:1.8.0_171]

at org.apache.sshd.common.signature.AbstractSignature.init(AbstractSignature.java:47)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.server.kex.AbstractDHGServer.next(AbstractDHGServer.java:91)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:425)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[281: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)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)[281: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_171]

at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[281:org.apache.sshd.core:0.14.0]

at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_171]

at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)[:1.8.0_171]

at sun.nio.ch.UnixAsynchronousSocketChannelImpl.implRead(UnixAsynchronousSocketChannelImpl.java:553)[:1.8.0_171]

at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:276)[:1.8.0_171]

at sun.nio.ch.AsynchronousSocketChannelImpl.read(AsynchronousSocketChannelImpl.java:297)[:1.8.0_171]

at java.nio.channels.AsynchronousSocketChannel.read(AsynchronousSocketChannel.java:420)[:1.8.0_171]

at org.apache.sshd.common.io.nio2.Nio2Session.startReading(Nio2Session.java:170)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:186)[281:org.apache.sshd.core:0.14.0]

at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:170)[281: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_171]

at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[281:org.apache.sshd.core:0.14.0]

at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_171]

at sun.nio.ch.Invoker$2.run(Invoker.java:218)[:1.8.0_171]

at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)[:1.8.0_171]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_171]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_171]

at java.lang.Thread.run(Thread.java:748)[:1.8.0_171]

Regards,

Duncan

Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at http://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/page/report-an-incident.php.

[Lars Kiesow]

Hi Duncan,
never used the SSH Server built into Karaf except once for testing but
just skimming over the reports, it sounds like generating a new,
stronger key would solve the issue, wouldn't it?
–Lars

[Greg Logan]

... Is this server enabled by default?  I thought we had turned it off?

G

--
You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencast.org.

[Stephen Marquard]

It’s not enabled by default.

 

If you want it, you have to:

 

1. Add it as a feature to your karaf feature.xml
2. Configure etc/users.properties and etc/org.apache.karaf.shell.cfg

 

I think our problem was an older hosts.key file on our dev server, as it seems like just removing hosts.key and restarting karaf fixed the ssh negotiation issue there.

 

Cheers

Stephen

 

---
Stephen Marquard, Learning Technologies Co-ordinator,
Centre for Innovation in Learning and Teaching (CILT)
University of Cape Town
http://www.cilt.uct.ac.za
stephen....@uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290

 

From: Greg Logan <gregor...@gmail.com>
Sent: 16 August 2018 04:57 PM
To: d...@opencast.org
Subject: Re: [OC Dev] Karaf SSH console

 

... Is this server enabled by default?  I thought we had turned it off?

 

G

 

On Thu, Aug 16, 2018 at 8:21 AM, Lars Kiesow <lki...@uos.de> wrote:

Hi Duncan,
never used the SSH Server built into Karaf except once for testing but
just skimming over the reports, it sounds like generating a new,
stronger key would solve the issue, wouldn't it?
–Lars

 

Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at http://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/page/report-an-incident.php.