[jira] [Commented] (SSHD-1230) sshd-netty logs all traffic on INFO level
[
https://issues.apache.org/jira/browse/SSHD-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17449176#comment-17449176
]
Robert Varga commented on SSHD-1230:
PR: https://github.com/apache/mina-sshd/pull/210
> sshd-netty logs all traffic on INFO level
> -
>
> Key: SSHD-1230
> URL: https://issues.apache.org/jira/browse/SSHD-1230
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.7.0
>Reporter: Robert Varga
>Priority: Major
>
> Enabling NettyIoServiceFactoryFactory leads to all traffic going through the
> SSHD to be logged on INFO level:
> {noformat}
> 2021-11-25T11:31:18,911 | INFO | nioEventLoopGroup-6-1 | LoggingHandler
> | 59 - io.netty.common - 4.1.69.Final | [id: 0x5ddc1968,
> L:/127.0.0.1:32834 - R:/127.0.0.1:17840] FLUSH2021-11-25T11:31:18,912 | INFO
> | nioEventLoopGroup-6-1 | LoggingHandler | 59 -
> io.netty.common - 4.1.69.Final | [id: 0x5ddc1968, L:/127.0.0.1:32834 -
> R:/127.0.0.1:17840] WRITE: 320B
> +-+
> | 0 1 2 3 4 5 6 7 8 9 a b c d e f |
> ++-++
> || bb 62 7e e1 9e 66 19 fc 26 2a d5 fa 33 07 ed 3b |.b~..f..&*..3..;|
> |0010| 75 6a 7b c5 dc 72 46 c8 75 82 12 83 35 16 11 a9 |uj{..rF.u...5...|
> |0020| 78 f8 58 69 81 41 94 55 bb e6 5e a4 3d 25 21 b5 |x.Xi.A.U..^.=%!.|
> |0030| 8f 00 6c 78 cd 11 dc e2 55 34 ac 51 9d e3 09 ec |..lxU4.Q|
> |0040| 42 bb c8 f7 af b2 82 e7 ab a3 61 13 0a cd 54 26 |B.a...T&|
> |0050| 51 bb de 66 a0 5c d6 23 94 d1 0b 7c 4a 33 90 b4 |Q..f.\.#...|J3..|
> |0060| 9e 04 26 5a a7 ba 77 4f fd 70 77 4d 73 65 de 9e |..&Z..wO.pwMse..|
> |0070| 48 de fc 22 ca 97 5c 10 66 a7 89 14 64 24 8c e6 |H.."..\.f...d$..|
> |0080| fe b1 ed b6 43 48 90 f8 ec 57 d8 ac 40 a5 83 35 |CH...W..@..5|
> |0090| af f7 a6 b3 ab 2b a8 b9 f2 b5 ec 7b ab e2 03 51 |.+.{...Q|
> |00a0| 55 18 95 4f 18 0b 53 8f 7e 86 2f 3e 19 78 c5 5c |U..O..S.~./>.x.\|
> |00b0| e7 42 8e d4 fe dc ab b5 e8 1b 30 51 e6 ff 35 aa |.B0Q..5.|
> |00c0| 56 25 c7 2c 8a 24 0c 1c d4 ce 5a 9a 2d 67 0b 6a |V%.,.$Z.-g.j|
> |00d0| af b4 38 bd 5b 75 0f 1a 1a 59 50 14 60 ff a4 68 |..8.[u...YP.`..h|
> |00e0| 1c 6a c8 eb d6 56 9e 35 7d 74 c7 06 4b a4 50 2f |.j...V.5}t..K.P/|
> |00f0| e7 91 ae 34 a4 60 0e 2e 2f bb a6 58 77 7f 4b 9c |...4.`../..Xw.K.|
> |0100| d2 5a 99 ee a5 b4 c1 5c 5a c1 2a 9b b4 6c 5c e0 |.Z.\Z.*..l\.|
> |0110| 4b e2 04 2e b2 32 df 88 52 74 65 ef c6 a8 45 87 |K2..Rte...E.|
> |0120| 64 c0 0b 41 8c b7 cb 85 75 7d 3c 3c d2 57 4e 0b |d..Au}<<.WN.|
> |0130| 98 f0 cb e3 2d ae b1 aa d1 b2 75 14 43 6d 46 8f
> |-.u.CmF.|{noformat}
> This is caused by NettyIoConnector explicitly setting the log level to info,
> overriding the netty-default level (debug). Also the identity of the class
> responsible for logging is squashed to LoggingHandler, which makes it
> difficult to control through normal logger configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1230) sshd-netty logs all traffic on INFO level
Robert Varga created SSHD-1230:
--
Summary: sshd-netty logs all traffic on INFO level
Key: SSHD-1230
URL: https://issues.apache.org/jira/browse/SSHD-1230
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.7.0
Reporter: Robert Varga
Enabling NettyIoServiceFactoryFactory leads to all traffic going through the
SSHD to be logged on INFO level:
{noformat}
2021-11-25T11:31:18,911 | INFO | nioEventLoopGroup-6-1 | LoggingHandler
| 59 - io.netty.common - 4.1.69.Final | [id: 0x5ddc1968,
L:/127.0.0.1:32834 - R:/127.0.0.1:17840] FLUSH2021-11-25T11:31:18,912 | INFO |
nioEventLoopGroup-6-1 | LoggingHandler | 59 - io.netty.common
- 4.1.69.Final | [id: 0x5ddc1968, L:/127.0.0.1:32834 - R:/127.0.0.1:17840]
WRITE: 320B
+-+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
++-++
|| bb 62 7e e1 9e 66 19 fc 26 2a d5 fa 33 07 ed 3b |.b~..f..&*..3..;|
|0010| 75 6a 7b c5 dc 72 46 c8 75 82 12 83 35 16 11 a9 |uj{..rF.u...5...|
|0020| 78 f8 58 69 81 41 94 55 bb e6 5e a4 3d 25 21 b5 |x.Xi.A.U..^.=%!.|
|0030| 8f 00 6c 78 cd 11 dc e2 55 34 ac 51 9d e3 09 ec |..lxU4.Q|
|0040| 42 bb c8 f7 af b2 82 e7 ab a3 61 13 0a cd 54 26 |B.a...T&|
|0050| 51 bb de 66 a0 5c d6 23 94 d1 0b 7c 4a 33 90 b4 |Q..f.\.#...|J3..|
|0060| 9e 04 26 5a a7 ba 77 4f fd 70 77 4d 73 65 de 9e |..&Z..wO.pwMse..|
|0070| 48 de fc 22 ca 97 5c 10 66 a7 89 14 64 24 8c e6 |H.."..\.f...d$..|
|0080| fe b1 ed b6 43 48 90 f8 ec 57 d8 ac 40 a5 83 35 |CH...W..@..5|
|0090| af f7 a6 b3 ab 2b a8 b9 f2 b5 ec 7b ab e2 03 51 |.+.{...Q|
|00a0| 55 18 95 4f 18 0b 53 8f 7e 86 2f 3e 19 78 c5 5c |U..O..S.~./>.x.\|
|00b0| e7 42 8e d4 fe dc ab b5 e8 1b 30 51 e6 ff 35 aa |.B0Q..5.|
|00c0| 56 25 c7 2c 8a 24 0c 1c d4 ce 5a 9a 2d 67 0b 6a |V%.,.$Z.-g.j|
|00d0| af b4 38 bd 5b 75 0f 1a 1a 59 50 14 60 ff a4 68 |..8.[u...YP.`..h|
|00e0| 1c 6a c8 eb d6 56 9e 35 7d 74 c7 06 4b a4 50 2f |.j...V.5}t..K.P/|
|00f0| e7 91 ae 34 a4 60 0e 2e 2f bb a6 58 77 7f 4b 9c |...4.`../..Xw.K.|
|0100| d2 5a 99 ee a5 b4 c1 5c 5a c1 2a 9b b4 6c 5c e0 |.Z.\Z.*..l\.|
|0110| 4b e2 04 2e b2 32 df 88 52 74 65 ef c6 a8 45 87 |K2..Rte...E.|
|0120| 64 c0 0b 41 8c b7 cb 85 75 7d 3c 3c d2 57 4e 0b |d..Au}<<.WN.|
|0130| 98 f0 cb e3 2d ae b1 aa d1 b2 75 14 43 6d 46 8f
|-.u.CmF.|{noformat}
This is caused by NettyIoConnector explicitly setting the log level to info,
overriding the netty-default level (debug). Also the identity of the class
responsible for logging is squashed to LoggingHandler, which makes it difficult
to control through normal logger configuration.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1028) SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed: 64"
[
https://issues.apache.org/jira/browse/SSHD-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225621#comment-17225621
]
Robert Varga commented on SSHD-1028:
Would it be possible to have a release with this fix?
Downstream we had to resort to this:
[https://jira.opendaylight.org/browse/NETCONF-736] :(
> SSH_MSG_DISCONNECT: 12 "Too many concurrent connections (64) - max. allowed:
> 64"
>
>
> Key: SSHD-1028
> URL: https://issues.apache.org/jira/browse/SSHD-1028
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
> Environment: bazel test
> //javatests/com/google/gerrit/acceptance/git:SshPushForReviewIT
>Reporter: David Ostrovsky
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm trying to migrate Gerrit to 2.5.0 and seeing this exception:
> {code}
> 80)
> pushCommitsWithSameTreeNoChanges(com.google.gerrit.acceptance.git.SshPushForReviewIT)
> com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 12 Too many concurrent
> connections (64) - max. allowed: 64
> at com.jcraft.jsch.Session.read(Session.java:1004)
> at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:198)
> at com.jcraft.jsch.Session.connect(Session.java:470)
> at com.jcraft.jsch.Session.connect(Session.java:183)
> at
> com.google.gerrit.acceptance.SshSession.getSession(SshSession.java:111)
> at com.google.gerrit.acceptance.SshSession.open(SshSession.java:46)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.initSsh(AbstractDaemonTest.java:541)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest.beforeTest(AbstractDaemonTest.java:456)
> at
> com.google.gerrit.acceptance.AbstractDaemonTest$1$1.evaluate(AbstractDaemonTest.java:230)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> com.google.testing.junit.runner.internal.junit4.CancellableRequestFactory$CancellableRunner.run(CancellableRequestFactory.java:108)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> com.google.testing.junit.runner.junit4.JUnit4Runner.run(JUnit4Runner.java:116)
> at
> com.google.testing.junit.runner.BazelTestRunner.runTestsInSuite(BazelTestRunner.java:159)
> at
> com.google.testing.junit.runner.BazelTestRunner.main(BazelTestRunner.java:85)
> {code
[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077165#comment-17077165
]
Robert Varga commented on SSHD-975:
---
This is OSGi runtime with Equinox. We have:
* sshd-osgi.jar, which contains AbstractFactoryManager and SshClient
* netty-util.jar, which contains NetconfSshClient, a subclass of SshClient
(and therefore a subclass of AbstractFactoryManager)
Obviously, each of those jars has its own ClassLoader, and hence when
AbstractFactoryManager calls getClass().getClassLoader(), it is an instance
invocation, hence it results in either SshClient.class.getClassLoader() (i.e.
sshd-osgi.jar) or NeconfSshClient.class.getClassLoader() (i.e. netty-util.jar).
netty-util.jar performs just some data shuffling, hence it does not interact
with anything in org.apache.sshd.common.\{forward,util.net} packages, so it
does not contain Import-Package OSGi MANIFEST.MF entries for those packages,
hence PortForwardingEventListener and SshdSocketAddress cannot be resolved
through it, which leads to the reported splat.
Now the Netty thing is a bit more convoluted: we are implementing a NETCONF
(RFC6241) endpoint, which is defining its own SSH subsystem ("netconf"), i.e.
sshd is used as a transport alternative to plain TCP sockets (or TLS). The
protocol logic itself is implemented in terms of Netty handlers.
So what is going on here is that we are running SSHD with NIO2 to get the SSH
session going, but once we establish the session, we open the "netconf" SSH
subsystem and funnel any data on it to a Netty channel, which is wired with
those handlers – hence the protocol implementation does not know nor care what
the actual transport is (see (1) in
[https://tools.ietf.org/html/rfc6241#page-9)]
Currently, we use plain SshClient async reads to achieve the funnelling, but
that has three major downsides:
* async read requires us to allocate an additional bounce buffer for each
session
* we have unnecessary queuing inside AbstractClientChannel, as we end up
pushing the data away anyway
* as we can have a large number (1+ sessions), that bounce buffer is small
(2KiB), which in turn causes fragmentation, which we need to reassemble at the
Netty layer
So we have a prototype, which subclasses SshClient so that (through some
ceremony) we end up with our own ClientChannel implementation, whose
doWriteData() just moves the data from provided byte[] into a Netty ByteBuf and
throws it into the the Netty pipeline for processing – minimizing buffering,
fragmentation and latency, hopefully significantly improving performance.
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultC
[jira] [Updated] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated SSHD-975:
--
Affects Version/s: 2.4.0
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [64:io.netty.common:4.1.45.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.IllegalArgumentException:
> org.apache.sshd.common.forward.PortForwardingEventListener referenced from a
> method is not visible from class loader
> at java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:858)
> ~[?:?]
> at
> java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:681)
> ~[?:?]
> at java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:627) ~[?:?]
> at java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:635) ~[?:?]
> at java.lang.reflect.Proxy.lambda$getProxyConstructor$0(Proxy.java:415)
> ~[?:?]
> at
> jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(AbstractClassLoaderValue.java:329)
> ~[?:?]
> at
> jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(AbstractClassLoaderValue.java:205)
> ~[?
[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077079#comment-17077079
]
Robert Varga commented on SSHD-975:
---
A workaround is to reference PortForwardingEventListener in the SshClient
subclass, but that is non-obvious, as all functionality is delivered by
SshClient (and really AbstractFactoryManager) and the workaround is not stable
in face of AbstractFactoryManager's default constructor changing (adding/moving
proxy interfaces).
The correct fix is to either use AbstractFactoryManager.class.getClassLoader()
or target interfaces' respective loaders.
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [64:io.netty.common:4.1.45.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.IllegalArgumentException:
> org.apache.sshd.common.forward.PortForwardingEventListener referenced from a
> method is not visible from class loader
> at java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:858)
> ~[?:?]
> at
> java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:681)
> ~[?:?]
> at java.lang.reflect.Proxy$ProxyBuilder
[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment
[
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077078#comment-17077078
]
Robert Varga commented on SSHD-975:
---
The problem here comes from AbstractFactoryManager specification of the class
loader. It is using getClassLoader(), which routes to netty-util's ClassLoader.
As netty-util is not referencing anything in "org.apache.sshd.common.forward"
package, that package is not imported into its classloader – and therefore
PortForwardingEventListener is not visible.
Looking at the git history, this issue was there since
40195ab466bb7ae97fd88c21b9a3394e78566ba9 (part of SSHD-555).
> SshClient subclasses fail in OSGi environment
> -
>
> Key: SSHD-975
> URL: https://issues.apache.org/jira/browse/SSHD-975
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to subclass SshClient and use it in OSGi environment can fail with
> the following:
> {noformat}
> 2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
> ChannelInitializer | 64 - io.netty.common - 4.1.45.Final |
> Failed to initialize a channel. Closing: [id: 0xfedebbf7]
> java.lang.ExceptionInInitializerError: null
> at
> org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
> ~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
> ~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
> at
> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
> [64:io.netty.common:4.1.45.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
> [67:io.netty.transport:4.1.45.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> [64:io.netty.common:4.1.45.Final]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [64:io.netty.common:4.1.45.Final]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> Caused by: java.lang.IllegalArgumentException:
> org.apache.sshd.common.forward.PortForwardingEventListener referenced from a
> method is not visible from class loader
> at java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:858)
> ~[?:?]
> at
> java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:681)
> ~[?:?]
> at java.lang.
[jira] [Created] (SSHD-975) SshClient subclasses fail in OSGi environment
Robert Varga created SSHD-975:
-
Summary: SshClient subclasses fail in OSGi environment
Key: SSHD-975
URL: https://issues.apache.org/jira/browse/SSHD-975
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.3.0
Reporter: Robert Varga
Attempting to subclass SshClient and use it in OSGi environment can fail with
the following:
{noformat}
2020-04-07T07:46:19,968 | WARN | nioEventLoopGroupCloseable-3-1 |
ChannelInitializer | 64 - io.netty.common - 4.1.45.Final | Failed
to initialize a channel. Closing: [id: 0xfedebbf7]
java.lang.ExceptionInInitializerError: null
at
org.opendaylight.netconf.client.SshClientChannelInitializer.initialize(SshClientChannelInitializer.java:43)
~[402:org.opendaylight.netconf.client:1.9.0.SNAPSHOT]
at
org.opendaylight.netconf.nettyutil.ReconnectPromise.lambda$connect$0(ReconnectPromise.java:54)
~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
at
org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:206)
~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
at
org.opendaylight.netconf.nettyutil.AbstractNetconfDispatcher$3.initChannel(AbstractNetconfDispatcher.java:203)
~[420:org.opendaylight.netconf.netty-util:1.9.0.SNAPSHOT]
at
io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:956)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:502)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:417)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:474)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
[64:io.netty.common:4.1.45.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
[64:io.netty.common:4.1.45.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
[67:io.netty.transport:4.1.45.Final]
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[64:io.netty.common:4.1.45.Final]
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[64:io.netty.common:4.1.45.Final]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[64:io.netty.common:4.1.45.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.IllegalArgumentException:
org.apache.sshd.common.forward.PortForwardingEventListener referenced from a
method is not visible from class loader
at java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(Proxy.java:858)
~[?:?]
at
java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(Proxy.java:681)
~[?:?]
at java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:627) ~[?:?]
at java.lang.reflect.Proxy$ProxyBuilder.(Proxy.java:635) ~[?:?]
at java.lang.reflect.Proxy.lambda$getProxyConstructor$0(Proxy.java:415)
~[?:?]
at
jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(AbstractClassLoaderValue.java:329)
~[?:?]
at
jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(AbstractClassLoaderValue.java:205)
~[?:?]
at java.lang.reflect.Proxy.getProxyConstructor(Proxy.java:413) ~[?:?]
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:1006) ~[?:?]
at
org.apache.sshd.common.util.EventListenerUtils.proxyWrapper(EventListenerUtils.java:193)
~[144:org.apache.sshd.osgi:2.3.0]
at
org.apache.sshd.common.helpers.AbstractFactoryManager.(AbstractFactoryManager.java:107)
~
[jira] [Commented] (SSHD-847) Split package across sshd-core and sshd-common causes OSGi load problem
[
https://issues.apache.org/jira/browse/SSHD-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635782#comment-16635782
]
Robert Varga commented on SSHD-847:
---
[~lgoldstein] I am currently tied down, I am not sure I can get to it sooner
than in about two weeks, though :( It definitely is on my radar, though.
> Split package across sshd-core and sshd-common causes OSGi load problem
> ---
>
> Key: SSHD-847
> URL: https://issues.apache.org/jira/browse/SSHD-847
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Robert Varga
>Priority: Major
> Labels: osgi
>
> sshd-core and sshd-common fail to install inside karaf-4.2.1 container, as
> the following error is reported:
> {noformat}
> Uses constraint violation. Unable to resolve resource org.apache.sshd.core
> [org.apache.sshd.core/2.1.0] because it exports package
> 'org.apache.sshd.common' and is also exposed to it from resource
> org.apache.sshd.common [org.apache.sshd.common/2.1.0] via the following
> dependency chain:
> org.apache.sshd.core [org.apache.sshd.core/2.1.0]
> import:
> (&(osgi.wiring.package=org.apache.sshd.client.config.hosts)(version>=2.1.0)(!(version>=3.0.0)))
> |
> export: osgi.wiring.package: org.apache.sshd.client.config.hosts;
> uses:=org.apache.sshd.common
> export: osgi.wiring.package=org.apache.sshd.common
> org.apache.sshd.common [org.apache.sshd.common/2.1.0]
> at
> org.apache.felix.resolver.ResolverImpl$UseConstraintError.toException(ResolverImpl.java:2471)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:420)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Until this is resolved I don't see how sshd-core is usable in OSGi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635405#comment-16635405 ] Robert Varga edited comment on SSHD-846 at 10/2/18 12:40 PM: - [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time based on how quickly our peer responds, during which we should be able to shed them # I am no expert on locking and the codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: ## Thread A: kexState.set(KexState.DONE) ## Thread A is scheduled out ## Thread B: kexState.compareAndSwap(KexState.DONE, KexState.RUN) ## Thread B: kex = ... ## Thread B is scheduled out ## Thread A: kex = null ## Thread B is scheduled in and accesses kex (which should be valid) ## NullPointerException was (Author: nite): [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time based on how quickly our peer responds, during which we should be able to shed it # I am no expert on locking and the codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: ## Thread A: kexState.set(KexState.DONE) ## Thread A is scheduled out ## Thread B: kexState.compareAndSwap(KexState.DONE, KexState.RUN) ## Thread B: kex = ... ## Thread B is scheduled out ## Thread A: kex = null ## Thread B is scheduled in and accesses kex (which should be valid) ## NullPointerException > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Assignee: Goldstein Lyor >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635405#comment-16635405 ] Robert Varga edited comment on SSHD-846 at 10/2/18 12:39 PM: - [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time based on how quickly our peer responds, during which we should be able to shed it # I am no expert on locking and the codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: ## Thread A: kexState.set(KexState.DONE) ## Thread A is scheduled out ## Thread B: kexState.compareAndSwap(KexState.DONE, KexState.RUN) ## Thread B: kex = ... ## Thread B is scheduled out ## Thread A: kex = null ## Thread B is scheduled in and accesses kex (which should be valid) ## NullPointerException was (Author: nite): [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time based on how quickly our peer responds, during which we should be able to shed it # I am no expert on locking and the codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: ## Thread A: kexState.set(KexState.DONE) ## Thread A is scheduled out ## Thread B: kexState.compareAndSwap(KexState.DONE, KexState.RUN) ## Thread B: kex = ... ## Thread B is scheduled out ## Thread A is scheduled in ## kex = null ## Thread B is scheduled in and accesses kex (which should be valid) ## NullPointerException > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Assignee: Goldstein Lyor >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635405#comment-16635405 ] Robert Varga edited comment on SSHD-846 at 10/2/18 12:37 PM: - [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time based on how quickly our peer responds, during which we should be able to shed it # I am no expert on locking and the codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: ## Thread A: kexState.set(KexState.DONE) ## Thread A is scheduled out ## Thread B: kexState.compareAndSwap(KexState.DONE, KexState.RUN) ## Thread B: kex = ... ## Thread B is scheduled out ## Thread A is scheduled in ## kex = null ## Thread B is scheduled in and accesses kex (which should be valid) ## NullPointerException was (Author: nite): [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time # I am no expert on locking and codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Assignee: Goldstein Lyor >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635405#comment-16635405 ] Robert Varga commented on SSHD-846: --- [~lgoldstein] thanks for the patch, two comments: # I think it is still useful to nullify KeyPairGenerators, as it allows them to be freed while the key exchange is going on – it can take some time # I am no expert on locking and codepaths, but it would seem that "kex = null" should happen before kexState.set(KexState.DONE) – otherwise the guard via compareAndSet() could be ineffective: > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Assignee: Goldstein Lyor >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-847) Split package across sshd-core and sshd-common causes OSGi load problem
[
https://issues.apache.org/jira/browse/SSHD-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635287#comment-16635287
]
Robert Varga commented on SSHD-847:
---
I am happy to wait for the next release, although it would be nice to have a
release with SSHD-840 fixed, getting SSHD-846 is worth the wait. For testing,
in OpenDaylight we use Karaf, so what we are doing is:
# generate feature.xmls
# test them using pax-exam
The artifacts are not published to Central (yet, it is a work in progress), but
you can find the harness in our packaging of sshd here:
[https://github.com/opendaylight/odlparent/blob/master/features/odl-apache-sshd/pom.xml]
. Perhaps you will find some of it useful.
> Split package across sshd-core and sshd-common causes OSGi load problem
> ---
>
> Key: SSHD-847
> URL: https://issues.apache.org/jira/browse/SSHD-847
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Robert Varga
>Priority: Major
> Labels: osgi
>
> sshd-core and sshd-common fail to install inside karaf-4.2.1 container, as
> the following error is reported:
> {noformat}
> Uses constraint violation. Unable to resolve resource org.apache.sshd.core
> [org.apache.sshd.core/2.1.0] because it exports package
> 'org.apache.sshd.common' and is also exposed to it from resource
> org.apache.sshd.common [org.apache.sshd.common/2.1.0] via the following
> dependency chain:
> org.apache.sshd.core [org.apache.sshd.core/2.1.0]
> import:
> (&(osgi.wiring.package=org.apache.sshd.client.config.hosts)(version>=2.1.0)(!(version>=3.0.0)))
> |
> export: osgi.wiring.package: org.apache.sshd.client.config.hosts;
> uses:=org.apache.sshd.common
> export: osgi.wiring.package=org.apache.sshd.common
> org.apache.sshd.common [org.apache.sshd.common/2.1.0]
> at
> org.apache.felix.resolver.ResolverImpl$UseConstraintError.toException(ResolverImpl.java:2471)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:420)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Until this is resolved I don't see how sshd-core is usable in OSGi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-847) Split package across sshd-core and sshd-common
[
https://issues.apache.org/jira/browse/SSHD-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635177#comment-16635177
]
Robert Varga commented on SSHD-847:
---
In order to load inside OSGi, the two artifacts need to be combined into a
single .jar, for example sshd-core-osgi. While we can do this downstream in
OpenDaylight, I suspect Karaf and others will hit this as soon as they try to
upgrade and hence such artifact should be provided by this project.
> Split package across sshd-core and sshd-common
> --
>
> Key: SSHD-847
> URL: https://issues.apache.org/jira/browse/SSHD-847
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Robert Varga
>Priority: Major
> Labels: osgi
>
> sshd-core and sshd-common fail to install inside karaf-4.2.1 container, as
> the following error is reported:
> {noformat}
> Uses constraint violation. Unable to resolve resource org.apache.sshd.core
> [org.apache.sshd.core/2.1.0] because it exports package
> 'org.apache.sshd.common' and is also exposed to it from resource
> org.apache.sshd.common [org.apache.sshd.common/2.1.0] via the following
> dependency chain:
> org.apache.sshd.core [org.apache.sshd.core/2.1.0]
> import:
> (&(osgi.wiring.package=org.apache.sshd.client.config.hosts)(version>=2.1.0)(!(version>=3.0.0)))
> |
> export: osgi.wiring.package: org.apache.sshd.client.config.hosts;
> uses:=org.apache.sshd.common
> export: osgi.wiring.package=org.apache.sshd.common
> org.apache.sshd.common [org.apache.sshd.common/2.1.0]
> at
> org.apache.felix.resolver.ResolverImpl$UseConstraintError.toException(ResolverImpl.java:2471)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:420)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Until this is resolved I don't see how sshd-core is usable in OSGi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-847) Split package across sshd-core and sshd-common
[
https://issues.apache.org/jira/browse/SSHD-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635167#comment-16635167
]
Robert Varga commented on SSHD-847:
---
This is a regression from 2.0.0 caused by the split done in SSHD-842.
> Split package across sshd-core and sshd-common
> --
>
> Key: SSHD-847
> URL: https://issues.apache.org/jira/browse/SSHD-847
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Robert Varga
>Priority: Critical
>
> sshd-core and sshd-common fail to install inside karaf-4.2.1 container, as
> the following error is reported:
> {noformat}
> Uses constraint violation. Unable to resolve resource org.apache.sshd.core
> [org.apache.sshd.core/2.1.0] because it exports package
> 'org.apache.sshd.common' and is also exposed to it from resource
> org.apache.sshd.common [org.apache.sshd.common/2.1.0] via the following
> dependency chain:
> org.apache.sshd.core [org.apache.sshd.core/2.1.0]
> import:
> (&(osgi.wiring.package=org.apache.sshd.client.config.hosts)(version>=2.1.0)(!(version>=3.0.0)))
> |
> export: osgi.wiring.package: org.apache.sshd.client.config.hosts;
> uses:=org.apache.sshd.common
> export: osgi.wiring.package=org.apache.sshd.common
> org.apache.sshd.common [org.apache.sshd.common/2.1.0]
> at
> org.apache.felix.resolver.ResolverImpl$UseConstraintError.toException(ResolverImpl.java:2471)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:420)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Until this is resolved I don't see how sshd-core is usable in OSGi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-847) Split package across sshd-core and sshd-common
Robert Varga created SSHD-847:
-
Summary: Split package across sshd-core and sshd-common
Key: SSHD-847
URL: https://issues.apache.org/jira/browse/SSHD-847
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.1.0
Reporter: Robert Varga
sshd-core and sshd-common fail to install inside karaf-4.2.1 container, as the
following error is reported:
{noformat}
Uses constraint violation. Unable to resolve resource org.apache.sshd.core
[org.apache.sshd.core/2.1.0] because it exports package
'org.apache.sshd.common' and is also exposed to it from resource
org.apache.sshd.common [org.apache.sshd.common/2.1.0] via the following
dependency chain:
org.apache.sshd.core [org.apache.sshd.core/2.1.0]
import:
(&(osgi.wiring.package=org.apache.sshd.client.config.hosts)(version>=2.1.0)(!(version>=3.0.0)))
|
export: osgi.wiring.package: org.apache.sshd.client.config.hosts;
uses:=org.apache.sshd.common
export: osgi.wiring.package=org.apache.sshd.common
org.apache.sshd.common [org.apache.sshd.common/2.1.0]
at
org.apache.felix.resolver.ResolverImpl$UseConstraintError.toException(ResolverImpl.java:2471)
at
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:420)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Until this is resolved I don't see how sshd-core is usable in OSGi.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635095#comment-16635095 ] Robert Varga commented on SSHD-846: --- Eyeballing the code some more, it seems we should also AbstractSession.kex to null once the key exchange completes. > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Assignee: Goldstein Lyor >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
[ https://issues.apache.org/jira/browse/SSHD-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SSHD-846: -- Affects Version/s: 1.6.0 1.7.0 > ECDH/HDG kex retains KeyPairGenerator > - > > Key: SSHD-846 > URL: https://issues.apache.org/jira/browse/SSHD-846 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 1.7.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > > Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF > sessions over SSH transport shows that around 16% of the heap is used by > Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for > ~26% of OpenDaylight's per-session memory overhead. > These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen > field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SSHD-846) ECDH/HDG kex retains KeyPairGenerator
Robert Varga created SSHD-846: - Summary: ECDH/HDG kex retains KeyPairGenerator Key: SSHD-846 URL: https://issues.apache.org/jira/browse/SSHD-846 Project: MINA SSHD Issue Type: Bug Affects Versions: 2.0.0 Reporter: Robert Varga Analysis of a heap dump of running OpenDaylight with 10K concurrent NETCONF sessions over SSH transport shows that around 16% of the heap is used by Bouncy Castle's KeyPairGeneratorSpi$EC and related objects – accounting for ~26% of OpenDaylight's per-session memory overhead. These objects are retained by org.apache.sshd.common.kex.ECDH's myKpairGen field, which is never used once a keypair is generated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
[ https://issues.apache.org/jira/browse/SSHD-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16576839#comment-16576839 ] Robert Varga commented on SSHD-840: --- Also Karaf 3.0.9 is still widely deployed, hence 0.14.1 would be very appreciated. > Unknown commands cause IllegalStateException instead of being correctly > handled > --- > > Key: SSHD-840 > URL: https://issues.apache.org/jira/browse/SSHD-840 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.14.0, 1.6.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > Fix For: 2.0.1 > > > As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a > different behavior than OpenSSH when faced unknowns – in this case coming > from a buggy server. > While OpenSSH was able to establish a session, OpenDaylight (using SSHD > 1.6.0) was not – throwing an IllegalStateException. > Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified > by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
[ https://issues.apache.org/jira/browse/SSHD-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SSHD-840: -- Affects Version/s: 0.14.0 > Unknown commands cause IllegalStateException instead of being correctly > handled > --- > > Key: SSHD-840 > URL: https://issues.apache.org/jira/browse/SSHD-840 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 0.14.0, 1.6.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > Fix For: 2.0.1 > > > As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a > different behavior than OpenSSH when faced unknowns – in this case coming > from a buggy server. > While OpenSSH was able to establish a session, OpenDaylight (using SSHD > 1.6.0) was not – throwing an IllegalStateException. > Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified > by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
[ https://issues.apache.org/jira/browse/SSHD-840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16576814#comment-16576814 ] Robert Varga commented on SSHD-840: --- Would it be possible to have a 1.6.1/1.7.1 with this fix, so Apache Karaf 4.2.x and 4.1.x can pick it up? > Unknown commands cause IllegalStateException instead of being correctly > handled > --- > > Key: SSHD-840 > URL: https://issues.apache.org/jira/browse/SSHD-840 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > Fix For: 2.0.1 > > > As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a > different behavior than OpenSSH when faced unknowns – in this case coming > from a buggy server. > While OpenSSH was able to establish a session, OpenDaylight (using SSHD > 1.6.0) was not – throwing an IllegalStateException. > Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified > by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
[ https://issues.apache.org/jira/browse/SSHD-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SSHD-840: -- Affects Version/s: 2.0.0 > Unknown commands cause IllegalStateException instead of being correctly > handled > --- > > Key: SSHD-840 > URL: https://issues.apache.org/jira/browse/SSHD-840 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > Fix For: 2.0.1 > > > As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a > different behavior than OpenSSH when faced unknowns – in this case coming > from a buggy server. > While OpenSSH was able to establish a session, OpenDaylight (using SSHD > 1.6.0) was not – throwing an IllegalStateException. > Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified > by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
[ https://issues.apache.org/jira/browse/SSHD-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SSHD-840: -- Fix Version/s: (was: 2.0.0) 2.0.1 > Unknown commands cause IllegalStateException instead of being correctly > handled > --- > > Key: SSHD-840 > URL: https://issues.apache.org/jira/browse/SSHD-840 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 1.6.0, 2.0.0 >Reporter: Robert Varga >Priority: Major > Fix For: 2.0.1 > > > As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a > different behavior than OpenSSH when faced unknowns – in this case coming > from a buggy server. > While OpenSSH was able to establish a session, OpenDaylight (using SSHD > 1.6.0) was not – throwing an IllegalStateException. > Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified > by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SSHD-840) Unknown commands cause IllegalStateException instead of being correctly handled
Robert Varga created SSHD-840: - Summary: Unknown commands cause IllegalStateException instead of being correctly handled Key: SSHD-840 URL: https://issues.apache.org/jira/browse/SSHD-840 Project: MINA SSHD Issue Type: Bug Affects Versions: 1.6.0 Reporter: Robert Varga Fix For: 2.0.0 As [https://github.com/CESNET/libnetconf2/issues/68] shows, MINA SSHD has a different behavior than OpenSSH when faced unknowns – in this case coming from a buggy server. While OpenSSH was able to establish a session, OpenDaylight (using SSHD 1.6.0) was not – throwing an IllegalStateException. Rather than throwing an exception, send an SSH_MSG_UNIMPLEMENTED as specified by [https://tools.ietf.org/html/rfc4253#section-11.4] . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
