[jira] [Updated] (SSHD-976) Add support for RSASSA-PSS keys

2020-04-07 Thread Lyor Goldstein (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lyor Goldstein updated SSHD-976:

Description: See [a|https://tools.ietf.org/html/rfc4056]ttached links  
(was: See [https://tools.ietf.org/html/rfc4056])

> Add support for RSASSA-PSS keys
> ---
>
> Key: SSHD-976
> URL: https://issues.apache.org/jira/browse/SSHD-976
> Project: MINA SSHD
>  Issue Type: New Feature
>Reporter: Lyor Goldstein
>Priority: Minor
>
> See [a|https://tools.ietf.org/html/rfc4056]ttached links



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Created] (SSHD-976) Add support for RSASSA-PSS keys

2020-04-07 Thread Lyor Goldstein (Jira)
Lyor Goldstein created SSHD-976:
---

 Summary: Add support for RSASSA-PSS keys
 Key: SSHD-976
 URL: https://issues.apache.org/jira/browse/SSHD-976
 Project: MINA SSHD
  Issue Type: New Feature
Reporter: Lyor Goldstein


See [https://tools.ietf.org/html/rfc4056]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Comment Edited] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Lyor Goldstein (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560
 ] 

Lyor Goldstein edited comment on SSHD-974 at 4/7/20, 8:46 PM:
--

Yes, I just confirmed it - the problem you describe occurs if 
{{eddsa-0.3.0.jar}} is not on your CLASSPATH. Please try it after fixing this 
problem and re-open the issue if it still occurs.


was (Author: lgoldstein):
Yes, I just confirmed it - the problem you describe occurs if 
eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing 
this problem and re-open the issue if it still occurs.

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Lyor Goldstein (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560
 ] 

Lyor Goldstein commented on SSHD-974:
-

Yes, I just confirmed it - the problem you describe occurs if 
eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing 
this problem and re-open the issue if it still occurs.

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Resolved] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Lyor Goldstein (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lyor Goldstein resolved SSHD-974.
-
Resolution: Invalid

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Lyor Goldstein (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077557#comment-17077557
 ] 

Lyor Goldstein commented on SSHD-974:
-

I cannot reproduce it in  any way  - however, I do  have another suspicion: is 
{{eddsa-0.3.0.jar}} on your CLASSPATH ? If not, then  the decoder for the 
{{ssh-ed25519}} key will not be available...

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Work logged] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-975?focusedWorklogId=417961=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-417961
 ]

ASF GitHub Bot logged work on SSHD-975:
---

Author: ASF GitHub Bot
Created on: 07/Apr/20 20:32
Start Date: 07/Apr/20 20:32
Worklog Time Spent: 10m 
  Work Description: lgoldstein commented on issue #118: [SSHD-975] Use 
AbstractFactoryManager's classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118#issuecomment-610605866
 
 
   >> Agreed, think we should just use the method without ClassLoader argument 
and instantiate the proxy in the classloader where the interface lives -- it's 
the simplest and guaranteed to work. What do you think?
   
   My thinking exactly - let me know if it fixes your problem. If so I will be 
more than happy to merge it to our _master_ branch. Please make sure that `mvn 
clean install` succeeds on the entire project.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 417961)
Time Spent: 0.5h  (was: 20m)

> 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: 0.5h
>  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 
> 

[GitHub] [mina-sshd] lgoldstein commented on issue #118: [SSHD-975] Use AbstractFactoryManager's classloader for proxies

2020-04-07 Thread GitBox
lgoldstein commented on issue #118: [SSHD-975] Use AbstractFactoryManager's 
classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118#issuecomment-610605866
 
 
   >> Agreed, think we should just use the method without ClassLoader argument 
and instantiate the proxy in the classloader where the interface lives -- it's 
the simplest and guaranteed to work. What do you think?
   
   My thinking exactly - let me know if it fixes your problem. If so I will be 
more than happy to merge it to our _master_ branch. Please make sure that `mvn 
clean install` succeeds on the entire project.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Updated] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Justin Crawford (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Crawford updated SSHD-974:
-
Attachment: id_ed25519.pub.hex

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Justin Crawford (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077483#comment-17077483
 ] 

Justin Crawford commented on SSHD-974:
--

The hex dump of the exact file it is parsing is attached, used xxd to dump to a 
hex file.[^id_ed25519.pub.hex]

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Comment Edited] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Justin Crawford (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077479#comment-17077479
 ] 

Justin Crawford edited comment on SSHD-974 at 4/7/20, 6:09 PM:
---

Apologies for the delay. I did some debugging of the code. It looks like when 
it checks the code at `AuthorizedKeyEntry.java:241` it will call 
`parseAuthorizedKeyEntry` then the one which takes a resolver that is set to 
null.
 It seems to parse each segment of the string deliminated by {{' '}} (space), 
starting first with calling:
 1. {{parseAuthorizedKeyEntry("ssh-ed25519}} 
C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q 
jus...@stacksmash.net", null)
 then
 2. 
{{parseAuthorizedKeyEntry("C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q
 jus...@stacksmash.net", null)}}
 and finally 
 3. {{parseAuthorizedKeyEntry("jus...@stacksmash.net", null)}}
 where the exception is thrown as {{startPos}} on line 291 of the same file 
returns -1 and thus an exception is thrown. I checked many times to see what 
values were passed to each functions. I have attached a screenshot of the 
_{{value}}_ and _{{line}}_ variables and nothing looked irregular. Please let 
me know if you would like me to debug additional things. This is part of an SSH 
daemon plugin for Minecraft so it runs in another thread and is a bit tricky to 
debug.
 !105624.png!


was (Author: justasic):
Apologies for the delay. I did some debugging of the code. It looks like when 
it checks the code at `AuthorizedKeyEntry.java:241` it will call 
`parseAuthorizedKeyEntry` then the one which takes a resolver that is set to 
null.
It seems to parse each segment of the string deliminated by {{' '}} (space), 
starting first with calling:
1. {{parseAuthorizedKeyEntry("{{ssh-ed25519}} 
C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q 
jus...@stacksmash.net", null)}}
then
2. 
{{parseAuthorizedKeyEntry("C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q
 jus...@stacksmash.net", null)}}
and finally 
3. {{parseAuthorizedKeyEntry("jus...@stacksmash.net", null)}}
where the exception is thrown as {{startPos}} on line 291 of the same file 
returns -1 and thus an exception is thrown. I checked many times to see what 
values were passed to each functions. I have attached a screenshot of the 
_{{value}}_ and _{{line}}_ variables and nothing looked irregular. Please let 
me know if you would like me to debug additional things. This is part of an SSH 
daemon plugin for Minecraft so it runs in another thread and is a bit tricky to 
debug.
!105624.png!

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, 
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Justin Crawford (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077479#comment-17077479
 ] 

Justin Crawford commented on SSHD-974:
--

Apologies for the delay. I did some debugging of the code. It looks like when 
it checks the code at `AuthorizedKeyEntry.java:241` it will call 
`parseAuthorizedKeyEntry` then the one which takes a resolver that is set to 
null.
It seems to parse each segment of the string deliminated by {{' '}} (space), 
starting first with calling:
1. {{parseAuthorizedKeyEntry("{{ssh-ed25519}} 
C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q 
jus...@stacksmash.net", null)}}
then
2. 
{{parseAuthorizedKeyEntry("C3NzaC1lZDI1NTE5IORpOmxZnzlKim1yuHsFmcENWdBr9JuNUXuqG48d932Q
 jus...@stacksmash.net", null)}}
and finally 
3. {{parseAuthorizedKeyEntry("jus...@stacksmash.net", null)}}
where the exception is thrown as {{startPos}} on line 291 of the same file 
returns -1 and thus an exception is thrown. I checked many times to see what 
values were passed to each functions. I have attached a screenshot of the 
_{{value}}_ and _{{line}}_ variables and nothing looked irregular. Please let 
me know if you would like me to debug additional things. This is part of an SSH 
daemon plugin for Minecraft so it runs in another thread and is a bit tricky to 
debug.
!105624.png!

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Updated] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys

2020-04-07 Thread Justin Crawford (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Crawford updated SSHD-974:
-
Attachment: 105624.png

> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with 
> the error message "Bad format (no key data delimiter)" however this key is 
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as 
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Work logged] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-975?focusedWorklogId=417659=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-417659
 ]

ASF GitHub Bot logged work on SSHD-975:
---

Author: ASF GitHub Bot
Created on: 07/Apr/20 13:08
Start Date: 07/Apr/20 13:08
Worklog Time Spent: 10m 
  Work Description: rovarga commented on issue #118: [SSHD-975] Use 
AbstractFactoryManager's classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118#issuecomment-610376299
 
 
   > If this change fixes the issue then I believe we should apply it to 
**all** the places where proxy wrappers are being created - which means also in 
`ScpCommandFactory`, `AbstractSftpSubsystemHelper`, 
`AbstractSftpEventListenerManager`, `AbstractConnectionService`, etc...
   
   Agreed, think we should just use the method without ClassLoader argument and 
instantiate the proxy in the classloader where the interface lives -- it's the 
simplest and guaranteed to work. What do you think?
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 417659)
Time Spent: 20m  (was: 10m)

> 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: 20m
>  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) 
> 

[GitHub] [mina-sshd] rovarga commented on issue #118: [SSHD-975] Use AbstractFactoryManager's classloader for proxies

2020-04-07 Thread GitBox
rovarga commented on issue #118: [SSHD-975] Use AbstractFactoryManager's 
classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118#issuecomment-610376299
 
 
   > If this change fixes the issue then I believe we should apply it to 
**all** the places where proxy wrappers are being created - which means also in 
`ScpCommandFactory`, `AbstractSftpSubsystemHelper`, 
`AbstractSftpEventListenerManager`, `AbstractConnectionService`, etc...
   
   Agreed, think we should just use the method without ClassLoader argument and 
instantiate the proxy in the classloader where the interface lives -- it's the 
simplest and guaranteed to work. What do you think?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Robert Varga (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[GitHub] [mina-sshd] lgoldstein commented on issue #103: [1.1.x]question about use mina-sshd as ssh-client and send shell command

2020-04-07 Thread GitBox
lgoldstein commented on issue #103: [1.1.x]question about use mina-sshd as 
ssh-client and send shell command
URL: https://github.com/apache/mina-sshd/pull/103#issuecomment-610328524
 
 
   >>  i have solved this issue .. i should set key.pem created by 1024
   
   I am  pretty sure this will not solve your problem (if it is what I 
remember) - you were just lucky to choose RSA key parameters that do not 
require padding - but this may change the next time you generate a new key - 
regardless of the key size
   
   >> maybe my mina-sshd version is low
   
   It is low - you should definitely upgrade...


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Lyor Goldstein (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077132#comment-17077132
 ] 

Lyor Goldstein commented on SSHD-975:
-

In general I am fine with the suggested change (see my previous comment) - I am 
not so clear though as to why {{getClass().getClassLoader()}}  would yield 
something different than {{AbstractFactoryManager.class.getClassLoader()}}. Can 
you provide some more details as to the mechanism involved here that make these 
class loaders different somehow ?

While on this subject - why are you using NETTY and not the default NIO2 
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?

> 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 
> 

[jira] [Comment Edited] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Lyor Goldstein (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077132#comment-17077132
 ] 

Lyor Goldstein edited comment on SSHD-975 at 4/7/20, 11:14 AM:
---

In general I am fine with the suggested change (see though my comment on the 
PR) - I am not so clear though as to why {{getClass().getClassLoader()}}  would 
yield something different than 
{{AbstractFactoryManager.class.getClassLoader()}}. Can you provide some more 
details as to the mechanism involved here that make these class loaders 
different somehow ?

While on this subject - why are you using NETTY and not the default NIO2 
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?


was (Author: lgoldstein):
In general I am fine with the suggested change (see my previous comment) - I am 
not so clear though as to why {{getClass().getClassLoader()}}  would yield 
something different than {{AbstractFactoryManager.class.getClassLoader()}}. Can 
you provide some more details as to the mechanism involved here that make these 
class loaders different somehow ?

While on this subject - why are you using NETTY and not the default NIO2 
service factory ? Have you tried NIO2 ? Does it exhibit the same behavior ?

> 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 
> 

[jira] [Updated] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Robert Varga (Jira)


 [ 
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)
>  

[GitHub] [mina-sshd] rovarga opened a new pull request #118: [SSHD-975] Use AbstractFactoryManager's classloader for proxies

2020-04-07 Thread GitBox
rovarga opened a new pull request #118: [SSHD-975] Use AbstractFactoryManager's 
classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118
 
 
   AbstractFactoryManager cannot make assumptions about the nature of the 
classloader returned by getClass().getClassLoader(). Use 
AbstractFactoryManager.class.getClassLoader() for loading proxies.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org



[jira] [Work logged] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/SSHD-975?focusedWorklogId=417573=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-417573
 ]

ASF GitHub Bot logged work on SSHD-975:
---

Author: ASF GitHub Bot
Created on: 07/Apr/20 09:23
Start Date: 07/Apr/20 09:23
Worklog Time Spent: 10m 
  Work Description: rovarga commented on pull request #118: [SSHD-975] Use 
AbstractFactoryManager's classloader for proxies
URL: https://github.com/apache/mina-sshd/pull/118
 
 
   AbstractFactoryManager cannot make assumptions about the nature of the 
classloader returned by getClass().getClassLoader(). Use 
AbstractFactoryManager.class.getClassLoader() for loading proxies.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 417573)
Remaining Estimate: 0h
Time Spent: 10m

> 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
>  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]
>   

[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Robert Varga (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 

[jira] [Commented] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Robert Varga (Jira)


[ 
https://issues.apache.org/jira/browse/SSHD-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 

[jira] [Created] (SSHD-975) SshClient subclasses fail in OSGi environment

2020-04-07 Thread Robert Varga (Jira)
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)
 

[GitHub] [mina-sshd] fengjian1993 commented on issue #103: [1.1.x]question about use mina-sshd as ssh-client and send shell command

2020-04-07 Thread GitBox
fengjian1993 commented on issue #103: [1.1.x]question about use mina-sshd as 
ssh-client and send shell command
URL: https://github.com/apache/mina-sshd/pull/103#issuecomment-610260895
 
 
   > 
   > 
   > It seems that you are still using an old version - the problem you 
describe seems familiar and I am pretty sure it is an issue we fixed in 
subsequent releases. As far as I can remember this had to do with RSA key 
padding being handled incorrectly - though the details escape me since this was 
a long time ago...
   
   hi, i have solved this issus. ;) maybe my mina-sshd version is low, i should 
set key.pem created by 1024. anyway, thanks for your warmly reply! 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org