[jira] [Closed] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed SSHD-1338.
-
Resolution: Fixed
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1338:
--
Fix Version/s: 2.12.1
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.12.1
>
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1338) SSHD 2.12 not binary compatible with JGIT 5.13
[
https://issues.apache.org/jira/browse/SSHD-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1338:
-
Assignee: Guillaume Nodet
> SSHD 2.12 not binary compatible with JGIT 5.13
> --
>
> Key: SSHD-1338
> URL: https://issues.apache.org/jira/browse/SSHD-1338
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Tomas Hofman
>Assignee: Guillaume Nodet
>Priority: Major
>
> Current version of SSHD still contains a dependency on JGIT 5.13. This is to
> keep SSHD compatible with Java 1.8, as JGIT 6.x requires Java 11.
> However SSHD 2.12 is not binary compatible with 2.9.x versions, which is the
> version that JGIT 5.13.x were build against. The result is that when SSHD
> 2.12 and JGIT 5.13 are used together, one can get NoSuchMethodErrors like
> here:
> {code}
> Caused by: java.lang.NoSuchMethodError: 'java.lang.Object
> org.apache.sshd.client.future.ConnectFuture.verify()'
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:189)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:142)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSession.connect(SshdSession.java:99)
> at
> org.eclipse.jgit@5.13.2.SP1-redhat-1//org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:235)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.9.3 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0, 2.9.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-981: Assignee: (was: Guillaume Nodet) > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > > This extension has been specified by [RFC 8308 - section > 3.3|https://tools.ietf.org/html/rfc8308#section-3.3] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1328) Hanging while executing rsync commands.
[ https://issues.apache.org/jira/browse/SSHD-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728233#comment-17728233 ] Guillaume Nodet commented on SSHD-1328: --- Could you reformat the code so that it's readable and provide the debug output log of the execution ? > Hanging while executing rsync commands. > > > Key: SSHD-1328 > URL: https://issues.apache.org/jira/browse/SSHD-1328 > Project: MINA SSHD > Issue Type: Bug > Environment: Linux and Solaris >Reporter: sivaprasad >Priority: Blocker > > Hi Team, > I hope all are doing great, I'm using Mina to execute remote commands > execution and file uploads/downloads. everything is working fine, but while > executing rsync commands( this command will take more than 1hr to complete) > Mina is hanging forever and not returning anything. > I have added HEARTBEAT in my code, but Mina is printing command output after > command execution is completed but I need to print command output parallel > with command execution. > I have attached my code, can someone look into this and help me to resolve > this issue’s. > > Thanks, > Siva. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.10.0 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1324: - Assignee: Guillaume Nodet > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1324. --- Resolution: Fixed > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1324) Rooted file system can leak informations
Guillaume Nodet created SSHD-1324: - Summary: Rooted file system can leak informations Key: SSHD-1324 URL: https://issues.apache.org/jira/browse/SSHD-1324 Project: MINA SSHD Issue Type: Bug Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484284#comment-17484284
]
Guillaume Nodet commented on SSHD-1243:
---
The {{GitSshdSessionProcess}} won't help you as you'd have to create the ssh
session and channel, it's just a thin wrapper. You just need the
{{ChannelExec}} which will allow you to run a remote command, so just call the
correct method on the {{{}ClientSession{}}}:
[https://github.com/apache/mina-sshd/blob/da2958172281ef20e51681afe036bd42c9cf843a/sshd-core/src/main/java/org/apache/sshd/client/session/ClientSession.java#L182]
The reason why there's no abstraction is that you need to configure the SSH
layer: host, port, user, password, ssh private key, host entries, ciphers,
macs, etc... So we probably won't provide such a thing.
And if you think you really need the {{GitSshdSessionProcess}} class, just copy
it, rename it, and hack it to suit your needs.
Btw, you're saying you're migrating from {{Jsch}} but afaik, it does not
provide this kind of abstraction (for the same reason I suppose). However, it
provides a {{ChannelExec}} in the same way as SSHD ...
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
>Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
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] [Closed] (SSHD-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed SSHD-1243.
-
Assignee: Guillaume Nodet
Resolution: Not A Problem
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
>Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
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-1243) is GitSshdSessionProcess class Git specific?
[
https://issues.apache.org/jira/browse/SSHD-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484225#comment-17484225
]
Guillaume Nodet commented on SSHD-1243:
---
It's not really git specific but definitely SSHD specific.
You can try to reuse it if you want, but there's nothing in the SSHD code that
will provide the magic you're looking for executing remote command.
I suggest you read the doc at
[https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#running-a-command-or-opening-a-shell]
and try building a small test with the plain SSHD api using the
{{{}Session.createExecChannel{}}}, you'll also find some examples at
https://github.com/apache/mina-sshd/blob/da2958172281ef20e51681afe036bd42c9cf843a/sshd-core/src/test/java/org/apache/sshd/client/ClientTest.java.
> is GitSshdSessionProcess class Git specific?
> -
>
> Key: SSHD-1243
> URL: https://issues.apache.org/jira/browse/SSHD-1243
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: dgü
>Priority: Major
>
> Hello!
> {{is org.apache.sshd.git.transport.GitSshdSessionProcess}} class Git specific
> ?
> Is there a generic SSHD class extending java.lang.Process ?
> Thanks in advance!
--
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-1239) PtyChannelConfiguration only support PtyType("xterm")?
[
https://issues.apache.org/jira/browse/SSHD-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483597#comment-17483597
]
Guillaume Nodet commented on SSHD-1239:
---
The Pty support is full working in SSHD on both client and server side, but it
has to be used with a Pty capable library.
I recommend having a look at JLine 3 which is working perfectly well with SSHD
(signals, terminal resize, etc...), and works with any kind of terminal which
fully advertise its capabilities.
The integration bits are available at
https://github.com/jline/jline3/tree/master/remote-ssh/src/main/java/org/jline/builtins/ssh
> PtyChannelConfiguration only support PtyType("xterm")?
> --
>
> Key: SSHD-1239
> URL: https://issues.apache.org/jira/browse/SSHD-1239
> Project: MINA SSHD
> Issue Type: Question
>Reporter: g3g4x5x6
>Assignee: Lyor Goldstein
>Priority: Major
>
> PtyChannelConfiguration only support PtyType
> "{color:#FF}_*xterm*_{color}"?
>
--
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-1240) Wrong password in URI works
[
https://issues.apache.org/jira/browse/SSHD-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481195#comment-17481195
]
Guillaume Nodet commented on SSHD-1240:
---
The expectation is that the password are ignored when matching file systems,
only the user is actually checked. This sounds reasonable because a given user
should not be able to log with two different passwords.
I would suggest not putting the password in the URIs at all.
> Wrong password in URI works
> ---
>
> Key: SSHD-1240
> URL: https://issues.apache.org/jira/browse/SSHD-1240
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
>Priority: Major
>
> Hello!
> This is another question encountered in SSHD-1238.
> I created URI instances with wrong passwords. But, It worked. The code:
> {noformat}
> */
> public static void main(String[] args) throws IOException,
> URISyntaxException {
> // Correct user info
> URI uri = new URI("sftp://deneme:deneme123@127.0.0.1:22;);
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> // Wrong password
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:random1@127.0.0.1:22/C:/Users/XXX/Desktop/sil/sftp/sil1.txt;));
> // Wrong password
> Path targetFile = Paths.get(new
> URI("sftp://deneme:random2@127.0.0.1:22/C:/Users/XXX/Desktop/sil/sftp/sil2.txt;));
> Files.copy(sourceFile, targetFile,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
>
> is this expected behaviour? I guess URI in _Paths.get_ matches only
> host:port:user with URI in _FileSystems.newFileSystem_
> Thanks in advance!
>
--
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] [Updated] (SSHD-1207) Large file get using WinSCP with Apache SFTP Server is not working
[
https://issues.apache.org/jira/browse/SSHD-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1207:
--
Description:
We have been using Apache SSHD version 2.5.1 for SFTP Server functionaity and
it was working very well with all the sftp clients. Recently we have upgraded
2.7.0 and facing issues with largefile downloads using WinSCP. Entire file is
not getting downloaded. Some time with out downloading the entire file WinSCP
is showing the transfer as complete. In the Apache SSHD logs, I see many EOF
status messages to the client. Not sure why so many EOF messages are exchanged
between the client and Server.
{code:java}
04 Aug 2021 21:38:10,841 [sshd-SftpSubsystem-46473-thread-1] DEBUG Nio2Session
- writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 16448 bytes
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4884997] processing
04 Aug 2021 21:38:10,842 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#149 sending command=94[SSH_MSG_CHANNEL_DATA] len=10734
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4884997]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4885253] processing
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4885253]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 10800 bytes
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#150 sending command=94[SSH_MSG_CHANNEL_DATA] len=41
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 96 bytes
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#151 sending command=94[SSH_MSG_CHANNEL_DATA] len=41
04 Aug 2021 21:38:10,843 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG Nio2Session - writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 96 bytes
04 Aug 2021 21:38:11,038 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-8]
DEBUG ChannelSession - handleData(ChannelSession[id=0,
recipient=256]-ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])
SSH_MSG_CHANNEL_DATA len=57{code}
was:
We have been using Apache SSHD version 2.5.1 for SFTP Server functionaity and
it was working very well with all the sftp clients. Recently we have upgraded
2.7.0 and facing issues with largefile downloads using WinSCP. Entire file
is not getting downloaded. Some time with out downloading the entire file
WinSCP is showing the transfer as complete. In the Apache SSHD logs, I see
many EOF status messages to the client. Not sure why so many EOF messages are
exchanged between the client and Server.
04 Aug 2021 21:38:10,841 [sshd-SftpSubsystem-46473-thread-1] DEBUG Nio2Session
- writeBuffer(Nio2Session[local=/10.15.102.66:59119,
remote=10.84.42.167/10.84.42.167:59334]) writing 16448 bytes
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ, id=4884997] processing
04 Aug 2021 21:38:10,842 [sshd-SshServer[6ad1bbb8](port=59119)-nio2-thread-1]
DEBUG ServerSessionImpl -
encode(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334]) packet
#149 sending command=94[SSH_MSG_CHANNEL_DATA] len=10734
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
doSendStatus(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[id=4884997]
SSH_FXP_STATUS (substatus=SSH_FX_EOF, lang=, msg=End of file)
04 Aug 2021 21:38:10,842 [sshd-SftpSubsystem-46473-thread-1] DEBUG
SftpSubsystem -
process(ServerSessionImpl[testuser1@10.84.42.167/10.84.42.167:59334])[length=53,
type=SSH_FXP_READ,
[jira] [Closed] (SSHD-1236) java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/management/ReflectionException;
[ https://issues.apache.org/jira/browse/SSHD-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed SSHD-1236. - Resolution: Not A Problem > java.lang.NoClassDefFoundError: Failed resolution of: > Ljavax/management/ReflectionException; > > > Key: SSHD-1236 > URL: https://issues.apache.org/jira/browse/SSHD-1236 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 > Environment: sshd-sftp:2.8.0 jdk 1.8.0 android :26 >Reporter: qiang,wei >Priority: Blocker > > with android target:26 > gradle:7.0 > agp:4.1.3, > sshd-sftp:2.8.0 > When setup a sftpServer, I got these problems. The reason is in andrid.jar > ,it lost many javax.*.class. > java.lang.NoClassDefFoundError: Failed resolution of: > Ljavax/management/ReflectionException; > How can i fix this issue? -- 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] [Resolved] (SSHD-1238) java.nio.file.FileSystemNotFoundException by SftpFileSystemProvider.getFileSystem
[
https://issues.apache.org/jira/browse/SSHD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1238.
---
Assignee: Guillaume Nodet
Resolution: Not A Problem
> java.nio.file.FileSystemNotFoundException by
> SftpFileSystemProvider.getFileSystem
> -
>
> Key: SSHD-1238
> URL: https://issues.apache.org/jira/browse/SSHD-1238
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
>Assignee: Guillaume Nodet
>Priority: Major
>
> Hello!
> The following code runs successfully:
> {noformat}
> public static void main(String[] args) throws IOException {
> URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", 22,
> "deneme", "deneme123");
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> Path localPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil1.txt");
> Path targetPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil2.txt");
> Files.copy(localPath, targetPath,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
> The following code fails:
> {noformat}
> public static void main(String[] args) throws URISyntaxException {
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:deneme123@127.0.0.1/C:/Users/XXX/Desktop/sil/sftp/sil.txt;));
> }
> {noformat}
> The exeption is:
> {noformat}
> Exception in thread "main" java.nio.file.FileSystemNotFoundException:
> 127.0.0.1:22:deneme
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getFileSystem(SftpFileSystemProvider.java:451)
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getPath(SftpFileSystemProvider.java:492)
> at java.nio.file.Paths.get(Paths.java:143)
> at com.ubtools.ubutils.UBTest.main(UBTest.java:30)
> {noformat}
>
> How can I solve this problem ?
> Thanks!
--
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-1238) java.nio.file.FileSystemNotFoundException by SftpFileSystemProvider.getFileSystem
[
https://issues.apache.org/jira/browse/SSHD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480860#comment-17480860
]
Guillaume Nodet commented on SSHD-1238:
---
The exception thrown indicates that the FileSystem was not found. Indeed, the
call to \{{java.nio.file.Paths.get}} will not automatically create the {{SFTP}}
filesystem, and you need to explicitely create it using a call to
{{FileSystems.newFileSystem}}.
The following will work:
{code:java}
URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", port,
"deneme", "deneme");
try (FileSystem fs = FileSystems.newFileSystem(uri, Collections.emptyMap())) {
Path sourceFile = Paths.get(new URI("sftp://deneme:deneme@127.0.0.1:; +
port + "/C:/Users/XXX/Desktop/sil/sftp/sil.txt"));
}
{code}
> java.nio.file.FileSystemNotFoundException by
> SftpFileSystemProvider.getFileSystem
> -
>
> Key: SSHD-1238
> URL: https://issues.apache.org/jira/browse/SSHD-1238
> Project: MINA SSHD
> Issue Type: Request
>Affects Versions: 2.8.0
> Environment: Java SE 8, Apache NetBeans IDE 12.5
>Reporter: dgü
>Priority: Major
>
> Hello!
> The following code runs successfully:
> {noformat}
> public static void main(String[] args) throws IOException {
> URI uri = SftpFileSystemProvider.createFileSystemURI("127.0.0.1", 22,
> "deneme", "deneme123");
> try (FileSystem fs = FileSystems.newFileSystem(uri,
> Collections.emptyMap())) {
> Path localPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil1.txt");
> Path targetPath =
> fs.getPath("C:/Users/XXX/Desktop/sil/sftp/sil2.txt");
> Files.copy(localPath, targetPath,
> StandardCopyOption.REPLACE_EXISTING);
> }
> }
> {noformat}
> The following code fails:
> {noformat}
> public static void main(String[] args) throws URISyntaxException {
> Path sourceFile = Paths.get(new
> URI("sftp://deneme:deneme123@127.0.0.1/C:/Users/XXX/Desktop/sil/sftp/sil.txt;));
> }
> {noformat}
> The exeption is:
> {noformat}
> Exception in thread "main" java.nio.file.FileSystemNotFoundException:
> 127.0.0.1:22:deneme
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getFileSystem(SftpFileSystemProvider.java:451)
> at
> org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.getPath(SftpFileSystemProvider.java:492)
> at java.nio.file.Paths.get(Paths.java:143)
> at com.ubtools.ubutils.UBTest.main(UBTest.java:30)
> {noformat}
>
> How can I solve this problem ?
> Thanks!
--
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] [Comment Edited] (SSHD-1235) Terminal resizing: with jediterm, when quit from vim, terminal don't resizing any more
[
https://issues.apache.org/jira/browse/SSHD-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467817#comment-17467817
]
Guillaume Nodet edited comment on SSHD-1235 at 1/3/22, 7:28 AM:
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
or
{code}
channel.sendWindowChange(columns, lines, height, width);
{code}
was (Author: gnt):
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
> Terminal resizing: with jediterm, when quit from vim, terminal don't
> resizing any more
> ---
>
> Key: SSHD-1235
> URL: https://issues.apache.org/jira/browse/SSHD-1235
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
> Environment: IDEA
>Reporter: g3g4x5x6
>Priority: Major
> Attachments: image-2022-01-03-02-41-16-780.png,
> image-2022-01-03-02-41-32-678.png
>
>
> h1. Create widget
>
> {code:java}
> ..
> private ClientSession getSession(SshClient client){
> ClientSession session;
> try {
> session = client.connect(this.user, this.host,
> this.port).verify(5000, TimeUnit.MILLISECONDS).getSession();
> session.addPasswordIdentity(this.pass);
> session.auth().verify(15, TimeUnit.SECONDS);
>
> session.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.IGNORE,
> Duration.ofMinutes(3));
> return session;
> } catch (IOException e) {
> e.printStackTrace();
> DialogUtil.error(e.getMessage());
> return null;
> }
> }
> ..
> private @NotNull JediTermWidget createTerminalWidget() {
> SshSettingsProvider sshSettingsProvider = new SshSettingsProvider();
> JediTermWidget widget = new JediTermWidget(sshSettingsProvider);
> widget.setTtyConnector(new DefaultTtyConnector(session));
> widget.start();
> return widget;
> } {code}
>
>
> h1. DefaultTtyConnector
> {code:java}
> package com.g3g4x5x6.ui.panels.ssh;
> import com.jediterm.terminal.Questioner;
> import com.jediterm.terminal.TtyConnector;
> import lombok.SneakyThrows;
> import lombok.extern.slf4j.Slf4j;
> import org.apache.sshd.client.channel.ChannelShell;
> import org.apache.sshd.client.session.ClientSession;
> import org.jetbrains.annotations.NotNull;
> import java.awt.*;
> import java.io.*;
> import java.nio.charset.StandardCharsets;
> import java.util.concurrent.TimeUnit;
> @Slf4j
> public class DefaultTtyConnector implements TtyConnector {
> private ClientSession session;
> private ChannelShell channel;
> private Dimension myPendingTermSize;
> private PipedOutputStream channelOut;
> private InputStream channelIn;
> private OutputStream outputStream;
> private BufferedReader reader;
> private BufferedWriter writer;
> public DefaultTtyConnector(ClientSession clientSession) {
> this.session = clientSession;
> }
> @Override
> public boolean init(Questioner questioner) {
> try {
> PipedOutputStream out = new PipedOutputStream();
> channelIn = new PipedInputStream(out);
> channelOut = new PipedOutputStream();
> PipedInputStream in = new PipedInputStream(channelOut);
> reader = new BufferedReader(new InputStreamReader(in,
> StandardCharsets.UTF_8));
> writer = new BufferedWriter(new OutputStreamWriter(out));
> channel = initClientChannel(session, channelIn, channelOut);
> outputStream = channel.getInvertedIn();
> } catch (IOException e) {
> e.printStackTrace();
> }
> return true;
> }
> private ChannelShell initClientChannel(ClientSession session, InputStream
> input, OutputStream output) throws IOException {
> ChannelShell channel = session.createShellChannel();
> String lang = (String) System.getenv().get("LANG");
> channel.setEnv("LANG", lang != null ? lang : "zh_CN.UTF-8");
> channel.setPtyType("xterm");
> channel.setUsePty(true);
> channel.setIn(input);
> channel.setOut(output);
> channel.setErr(output);
> channel.open().verify(3000, TimeUnit.MILLISECONDS);
> return channel;
> }
> @SneakyThrows
> @Override
> public void close() {
> channel.close();
> }
> @Override
> public String
[jira] [Commented] (SSHD-1235) Terminal resizing: with jediterm, when quit from vim, terminal don't resizing any more
[
https://issues.apache.org/jira/browse/SSHD-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467817#comment-17467817
]
Guillaume Nodet commented on SSHD-1235:
---
The setPtyLines and setPtyColumns methods can only be used to configure the
initial terminal size and have no effect after the terminal being open.
To propagate terminal changes once it has been opened, you need to use
{code}
channel.sendWindowChange(columns, lines);
{code}
> Terminal resizing: with jediterm, when quit from vim, terminal don't
> resizing any more
> ---
>
> Key: SSHD-1235
> URL: https://issues.apache.org/jira/browse/SSHD-1235
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
> Environment: IDEA
>Reporter: g3g4x5x6
>Priority: Major
> Attachments: image-2022-01-03-02-41-16-780.png,
> image-2022-01-03-02-41-32-678.png
>
>
> h1. Create widget
>
> {code:java}
> ..
> private ClientSession getSession(SshClient client){
> ClientSession session;
> try {
> session = client.connect(this.user, this.host,
> this.port).verify(5000, TimeUnit.MILLISECONDS).getSession();
> session.addPasswordIdentity(this.pass);
> session.auth().verify(15, TimeUnit.SECONDS);
>
> session.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.IGNORE,
> Duration.ofMinutes(3));
> return session;
> } catch (IOException e) {
> e.printStackTrace();
> DialogUtil.error(e.getMessage());
> return null;
> }
> }
> ..
> private @NotNull JediTermWidget createTerminalWidget() {
> SshSettingsProvider sshSettingsProvider = new SshSettingsProvider();
> JediTermWidget widget = new JediTermWidget(sshSettingsProvider);
> widget.setTtyConnector(new DefaultTtyConnector(session));
> widget.start();
> return widget;
> } {code}
>
>
> h1. DefaultTtyConnector
> {code:java}
> package com.g3g4x5x6.ui.panels.ssh;
> import com.jediterm.terminal.Questioner;
> import com.jediterm.terminal.TtyConnector;
> import lombok.SneakyThrows;
> import lombok.extern.slf4j.Slf4j;
> import org.apache.sshd.client.channel.ChannelShell;
> import org.apache.sshd.client.session.ClientSession;
> import org.jetbrains.annotations.NotNull;
> import java.awt.*;
> import java.io.*;
> import java.nio.charset.StandardCharsets;
> import java.util.concurrent.TimeUnit;
> @Slf4j
> public class DefaultTtyConnector implements TtyConnector {
> private ClientSession session;
> private ChannelShell channel;
> private Dimension myPendingTermSize;
> private PipedOutputStream channelOut;
> private InputStream channelIn;
> private OutputStream outputStream;
> private BufferedReader reader;
> private BufferedWriter writer;
> public DefaultTtyConnector(ClientSession clientSession) {
> this.session = clientSession;
> }
> @Override
> public boolean init(Questioner questioner) {
> try {
> PipedOutputStream out = new PipedOutputStream();
> channelIn = new PipedInputStream(out);
> channelOut = new PipedOutputStream();
> PipedInputStream in = new PipedInputStream(channelOut);
> reader = new BufferedReader(new InputStreamReader(in,
> StandardCharsets.UTF_8));
> writer = new BufferedWriter(new OutputStreamWriter(out));
> channel = initClientChannel(session, channelIn, channelOut);
> outputStream = channel.getInvertedIn();
> } catch (IOException e) {
> e.printStackTrace();
> }
> return true;
> }
> private ChannelShell initClientChannel(ClientSession session, InputStream
> input, OutputStream output) throws IOException {
> ChannelShell channel = session.createShellChannel();
> String lang = (String) System.getenv().get("LANG");
> channel.setEnv("LANG", lang != null ? lang : "zh_CN.UTF-8");
> channel.setPtyType("xterm");
> channel.setUsePty(true);
> channel.setIn(input);
> channel.setOut(output);
> channel.setErr(output);
> channel.open().verify(3000, TimeUnit.MILLISECONDS);
> return channel;
> }
> @SneakyThrows
> @Override
> public void close() {
> channel.close();
> }
> @Override
> public String getName() {
> return "SSH";
> }
> @Override
> public int read(char[] chars, int i, int i1) throws IOException {
> return reader.read(chars, i, i1);
> }
> @Override
> public void write(byte[] bytes) throws IOException {
> outputStream.write(bytes);
> outputStream.flush();
> }
> @Override
> public boolean isConnected() {
> return channel.isOpen();
>
[jira] [Commented] (SSHD-1169) Sftp Server throughput is lagging for concurrent threads
[ https://issues.apache.org/jira/browse/SSHD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458250#comment-17458250 ] Guillaume Nodet commented on SSHD-1169: --- At first glance, the file size seems to have an effect. But the test data does not really seem consistent enough to find out what the problem is. Could you try maybe with an additional smaller file size ? And could you publish the project to GitHub to reproduce the data ? > Sftp Server throughput is lagging for concurrent threads > > > Key: SSHD-1169 > URL: https://issues.apache.org/jira/browse/SSHD-1169 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Susmit Sarkar >Priority: Blocker > Attachments: image-2021-05-19-10-27-20-261.png > > > Hello Team, > We are seeing a considerably low throughput for large-sized file (100Mb sized > file during concurrent execution) > We did some load testing and the throughputs sometimes increase (when we do a > VM reboot for 1st run) and sometimes its pretty low compare to commercial > servers > > *2000 cycle runs | 20 concurrent threads | 100mb files == Throughput is 0.94 > documents per seconds* > For a commercial server, it's around 1.17 documents per second. > Now if we do a server reboot and re-execute the test then the throughput > increases by leaps and bounds > *2000 cycle runs | 20 concurrent threads | 100 MB files == Throughput is 1.90 > documents per seconds (More than 100 percent)* > *cycle means 100 MB file upload times, 2000 means 2000times*100 MB which got > distributed by 20 concurrent sftp sessions* > I am using IO Factory as NIO2, and below are the combinations for different > NIO worker threads > !image-2021-05-19-10-27-20-261.png! > We are pretty confused and need help. For small files, Apache performed very > well the throughput was 30 percent better than commercial server, but for > large files, we are seeing these issues sometimes (mostly with reboot it > performs good, but after that run its starts lagging) > nio-workers ===> *varies from the chart above* > max-auth-requests ===> 3 > Compression ===> NONE > max-concurrent-sessions ===> 2147483647 > packet-size ===> 65536 > idle-timeout ===> 30 > server-identification ===> SFTP Server > window-size ===> 4194304 > we are setting currently all this properties to *SshServer*, is there any > performance tuning parameter can be used? > -- 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] [Updated] (SSHD-1162) Make sure the project is built using a 1.8
[ https://issues.apache.org/jira/browse/SSHD-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1162: -- Fix Version/s: (was: 2.8.0) > Make sure the project is built using a 1.8 > - > > Key: SSHD-1162 > URL: https://issues.apache.org/jira/browse/SSHD-1162 > Project: MINA SSHD > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 2.7.1 > > > If not, the Buffer.flip() methods can be built using JDK 11 methods and cause > linking errors when run at JDK 8. -- 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] [Resolved] (SSHD-1225) NOTICE: wrong copyright year range
[
https://issues.apache.org/jira/browse/SSHD-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1225.
---
Fix Version/s: 2.7.1
Assignee: Guillaume Nodet
Resolution: Fixed
Fixed with
https://github.com/apache/mina-sshd/commit/80e57cfaa7bc0d36deecf19b2fc7c12e18427593
> NOTICE: wrong copyright year range
> --
>
> Key: SSHD-1225
> URL: https://issues.apache.org/jira/browse/SSHD-1225
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.7.0
>Reporter: Thomas Wolf
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.7.1
>
>
> The NOTICE files included in the JAR artifacts published to maven central say
> for instance for 2.7.0:
> {code:java}
> Apache MINA SSHD
> Copyright 2008-2020 The Apache Software Foundation
> {code}
> This is wrong. 2.7.0 was released in 2021, so it must say 2008-2021.
> It's not clear to me where this comes from, but I find [this property
> setting|https://github.com/apache/mina-sshd/blob/8e6e907e3/pom.xml#L86] in
> our root pom suspicious.
> For the sshd-osgi artifact we get a range of 2018-2020, which I find strange
> given that this is just a shading of sshd-common and sshd-core. Lower end of
> the range should also be 2008.
> These NOTICE files appear to be generated by the Apache root pom; there's a
> template in org.apache:apache-jar-resource-bundle:1.4 which uses a
> ${projectTimespan} variable, but I don't see where _that_ is set.
--
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] [Resolved] (SSHD-1213) Update tarLongFileMode to use POSIX
[ https://issues.apache.org/jira/browse/SSHD-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1213. --- Fix Version/s: 2.7.1 Resolution: Fixed > Update tarLongFileMode to use POSIX > --- > > Key: SSHD-1213 > URL: https://issues.apache.org/jira/browse/SSHD-1213 > Project: MINA SSHD > Issue Type: Bug >Reporter: Roberto Oliveira >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.7.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Mina sshd fails to build when the UID and/or GID of the user who executed the > build is bigger than 2097151. This is happening when building this project in > an OpenShift environment. > A fix for this is to use the TarArchiver behavior POSIX instead of GNU. -- 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] [Assigned] (SSHD-1213) Update tarLongFileMode to use POSIX
[ https://issues.apache.org/jira/browse/SSHD-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1213: - Assignee: Guillaume Nodet > Update tarLongFileMode to use POSIX > --- > > Key: SSHD-1213 > URL: https://issues.apache.org/jira/browse/SSHD-1213 > Project: MINA SSHD > Issue Type: Bug >Reporter: Roberto Oliveira >Assignee: Guillaume Nodet >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Mina sshd fails to build when the UID and/or GID of the user who executed the > build is bigger than 2097151. This is happening when building this project in > an OpenShift environment. > A fix for this is to use the TarArchiver behavior POSIX instead of GNU. -- 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-1201) Sever Keys name changed post 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387990#comment-17387990 ] Guillaume Nodet commented on SSHD-1201: --- [~Susmit07] This looks related https://issues.apache.org/jira/browse/SSHD-1163 > Sever Keys name changed post 2.7.0 > -- > > Key: SSHD-1201 > URL: https://issues.apache.org/jira/browse/SSHD-1201 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Susmit Sarkar >Priority: Blocker > Fix For: 2.7.0 > > > Hello Team, > We upgrade to 2.7.0 from 2.5.1 > we are seeing an issue > > String hostkey = > sftpClient.getSession().getNegotiatedKexParameter(KexProposalOption.SERVERKEYS); > > > Host Key in 2.5.1 was *ssh-rsa* and now with the upgrade to 2.7.0 all our > test cases are failing as the API is returning *rsa-sha2-512* > Please note the keys were actually created using ssh-rsa using 2.5.1 library > > Thanks, > Susmit > -- 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-1182) skip() doesn't work properly in SftpInputStreamAsync
[ https://issues.apache.org/jira/browse/SSHD-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363423#comment-17363423 ] Guillaume Nodet commented on SSHD-1182: --- Could you write an additional unit test in SftpTest please ? > skip() doesn't work properly in SftpInputStreamAsync > > > Key: SSHD-1182 > URL: https://issues.apache.org/jira/browse/SSHD-1182 > Project: MINA SSHD > Issue Type: Bug >Reporter: Pavel Stetsuk >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > skip() doesn't work properly in SftpInputStreamAsync if executed before read > a data. > In this case data read from the beginning and skip() is ignored -- 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-1178) SOCKS5 proxy stand-alone code
[ https://issues.apache.org/jira/browse/SSHD-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1178. --- Resolution: Not A Problem Maybe you could start by reading the doc: https://github.com/apache/mina-sshd/blob/master/docs/port-forwarding.md > SOCKS5 proxy stand-alone code > - > > Key: SSHD-1178 > URL: https://issues.apache.org/jira/browse/SSHD-1178 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Blocker > > Hello Team, > I want to create a SOCKS5 server using MINA sshd. I am not getting sure from > where to start. Shall be really grateful if someone can help with an example > code for standalone proxy server using mina sshd > Are SOCKS5 proxy and SSH Jumps both same? > > Thanks, > Susmit -- 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-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1181.
---
Fix Version/s: 2.7.1
Resolution: Fixed
https://github.com/apache/mina-sshd/commit/3db721d9a109d9aa80b3a662c43b57458acd99e4
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: SFTP, mina, sshd
> Fix For: 2.7.1
>
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
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-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360319#comment-17360319
]
Guillaume Nodet commented on SSHD-1181:
---
I've been able to reproduce the problem. The first thing was to change the
server side sftp code to send this EOF indicator when it makes sense. I should
be able to commit a fix with a test tomorrow.
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Major
> Labels: SFTP, mina, sshd
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
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] [Assigned] (SSHD-1181) SFTP Get downloads empty file from servers which supports EOF indication after data
[
https://issues.apache.org/jira/browse/SSHD-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1181:
-
Assignee: Guillaume Nodet
> SFTP Get downloads empty file from servers which supports EOF indication
> after data
> ---
>
> Key: SSHD-1181
> URL: https://issues.apache.org/jira/browse/SSHD-1181
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: SFTP, mina, sshd
>
> So, apparently there's a bug in Mina implementation when downloading the
> file, which is smaller than Mina's buffer (meaning it gets read in one
> iteration), from servers, which send EOF indicator at the end of data
> (https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#[section-9.3|https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-9.3]).
> The bug seems to be in setting up EOF indicator in
> {noformat}
> org.apache.sshd.sftp.client.impl.SftpInputStreamAsync#pollBuffer{noformat}
> prematurely (one iteration sooner), trace with me this example situation -
> download of the small file (14 B):
> At some point we arrive to mentioned function _pollBuffer()_, note that
> _this.pendingReads_ is set to 2. In first call of _pollBuffer()_ we go
> through this code on receiving SSH_FXP_DATA
> {code:java}
> if (type == SftpConstants.SSH_FXP_DATA) {
> int dlen = buf.getInt();
> int rpos = buf.rpos();
> buf.rpos(rpos + dlen);
> Boolean b = SftpHelper.getEndOfFileIndicatorValue(buf,
> client.getVersion());
> if ((b != null) && b.booleanValue()) {
> eofIndicator = true;
> }{code}
> Here, consider this situation, we're downloading file with 14B, remote server
> adds EOF indicator to the end of the data, so it makes 15B, let's add some
> necessary overhead (size etc.) which is, according to my experience, 13B, so
> we receive 15 + 13 = 28B into initial buffer.
> Now, if we populate these variables, _dlen_ = 14B (file size), _rpos_ = 13
> (overhead), and we set _buf.rpos_ to 27 (14 + 13), but _wpos_ is at the
> moment equal to 28B, as that's what we received. (We're not taking EOF into
> account here)
> Then the _SftpHelper.getEndOfFileIndicatorValue_ is called, which in it's
> implementation looks like this:
> {code:java}
> public static Boolean getEndOfFileIndicatorValue(Buffer buffer, int version) {
> return (version < SftpConstants.SFTP_V6) || (buffer.available() < 1) ?
> null : buffer.getBoolean();
> }
> {code}
> Pay attention to the _buffer.available()_ function as it's implemented like
> this:
> {code:java}
> public int available() {
> return wpos - rpos;
> }
> {code}
> therefore returning 1 (28 - 27), condition is then resolved in
> _SftpHelper.getEndOfFileIndicatorValue_ as a true and true is also returned
> to the _pollBuffer_ and _eofIndicator_ is set to true.
> If you'd keep tracing further, you'd find out that the buffer is then never
> read and returned from _SftpInputStreamAsync_ class, just because
> _eofIndicator_ was set sooner than it should have been.
>
>
--
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-1179) Getting OOM after upgrading to 2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359905#comment-17359905
]
Guillaume Nodet edited comment on SSHD-1179 at 6/9/21, 11:28 AM:
-
The most probable reason is that the {{SftpSubsystem}} are not closed
correctly. Those are closed automatically when the server channel is closed,
which happens when the client closes the channel or the connection.
was (Author: gnt):
The most probable reason is that the {{SftpSubsystem}} are not closed correctly.
> Getting OOM after upgrading to 2.6.0
>
>
> Key: SSHD-1179
> URL: https://issues.apache.org/jira/browse/SSHD-1179
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Subramaniajeeva
>Priority: Critical
>
> I upgraded mina version from 2.3.0 to 2.6.0 2 months back. Since then I could
> see the number of JVM threads keep on increasing(till ~12500), leading to OOM
> in production systems.
> Here is the stack trace with 2100+ similar threads:
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park({color:#80}Native Method{color})
> - parking to wait for *<0x00079f7630c8>* (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park({color:#80}LockSupport.java:175{color})
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await({color:#80}AbstractQueuedSynchronizer.java:2039{color})
> at
> java.util.concurrent.LinkedBlockingQueue.take({color:#80}LinkedBlockingQueue.java:442{color})
> at
> org.apache.sshd.sftp.server.SftpSubsystem.run({color:#80}SftpSubsystem.java:267{color})
> at
> java.util.concurrent.Executors$RunnableAdapter.call({color:#80}Executors.java:511{color})
> at
> java.util.concurrent.FutureTask.run({color:#80}FutureTask.java:266{color})
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker({color:#80}ThreadPoolExecutor.java:1149{color})
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run({color:#80}ThreadPoolExecutor.java:624{color})
> at java.lang.Thread.run({color:#80}Thread.java:748{color})
>
> I tried to debug and I'm not able to isolate the root cause. Is it identified
> and fixed already in 2.7.0?
> [~lgoldstein] Any help would be appreciated.
>
--
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-1179) Getting OOM after upgrading to 2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359905#comment-17359905
]
Guillaume Nodet commented on SSHD-1179:
---
The most probable reason is that the {{SftpSubsystem}} are not closed correctly.
> Getting OOM after upgrading to 2.6.0
>
>
> Key: SSHD-1179
> URL: https://issues.apache.org/jira/browse/SSHD-1179
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Subramaniajeeva
>Priority: Critical
>
> I upgraded mina version from 2.3.0 to 2.6.0 2 months back. Since then I could
> see the number of JVM threads keep on increasing(till ~12500), leading to OOM
> in production systems.
> Here is the stack trace with 2100+ similar threads:
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park({color:#80}Native Method{color})
> - parking to wait for *<0x00079f7630c8>* (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park({color:#80}LockSupport.java:175{color})
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await({color:#80}AbstractQueuedSynchronizer.java:2039{color})
> at
> java.util.concurrent.LinkedBlockingQueue.take({color:#80}LinkedBlockingQueue.java:442{color})
> at
> org.apache.sshd.sftp.server.SftpSubsystem.run({color:#80}SftpSubsystem.java:267{color})
> at
> java.util.concurrent.Executors$RunnableAdapter.call({color:#80}Executors.java:511{color})
> at
> java.util.concurrent.FutureTask.run({color:#80}FutureTask.java:266{color})
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker({color:#80}ThreadPoolExecutor.java:1149{color})
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run({color:#80}ThreadPoolExecutor.java:624{color})
> at java.lang.Thread.run({color:#80}Thread.java:748{color})
>
> I tried to debug and I'm not able to isolate the root cause. Is it identified
> and fixed already in 2.7.0?
> [~lgoldstein] Any help would be appreciated.
>
--
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-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354497#comment-17354497 ] Guillaume Nodet commented on SSHD-1176: --- The changelog has been updated. SSH jumps ([http://issues.apache.org/jira/browse/SSHD-1047)] are not related to SOCKS proxies and those were implemented in 2.6.0. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- 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-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354484#comment-17354484 ] Guillaume Nodet commented on SSHD-1176: --- The only issue I know about SOCKS5 is https://issues.apache.org/jira/browse/SSHD-1008 which is not resolved, so it's definitely not part of any release atm. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- 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-1176) Upgrade from 2.5.1 to 2.7.0
[ https://issues.apache.org/jira/browse/SSHD-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1735#comment-1735 ] Guillaume Nodet commented on SSHD-1176: --- 2.7.0 is now available in central. > Upgrade from 2.5.1 to 2.7.0 > --- > > Key: SSHD-1176 > URL: https://issues.apache.org/jira/browse/SSHD-1176 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello Team, > We are currently in 2.5.1 and it's pretty stable, but we are planning to > upgrade to 2.7.0. > Is it justified to update to 2.7.0 or 2.6.0 w.r.t stability? > Do we expect any new features with respect to SOCKS5 proxy support that will > help us. I checked the changes.md but couldn't find any, although there were > few features related to forwarding port and filter. > I didn't found 2.7.0 listed in maven repository, when can we expect the same > Thank you, > Best Regards, > Susmit > -- 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-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354432#comment-17354432
]
Guillaume Nodet commented on SSHD-1173:
---
Yes, using a configurable timeout would be better indeed.
The {{send}} method is calling {{verify}} to make sure that the message has
actually been written. If the thread is never released, it should indicate
that the packet has not been written yet. The most probable cause is that the
server does not handle the SSH window correctly and never sends
{{SSH_MSG_CHANNEL_WINDOW_ADJUST}} to tell the client it can send more data. If
you know the target server, maybe you can perform a test transfer (bit enough)
and see if the server ever sends those messages ?
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
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-1162) Make sure the project is built using a 1.8
[
https://issues.apache.org/jira/browse/SSHD-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1162.
---
Resolution: Fixed
{code}
commit d15644325e254ec1bedb9cd4e5aa4a6a3adb63d9 (HEAD -> master, origin/master,
origin/HEAD)
Author: Guillaume Nodet
Date: Wed May 19 15:03:02 2021 +0200
Make sure the project is built using with JDK 8 during releases
{code}
> Make sure the project is built using a 1.8
> -
>
> Key: SSHD-1162
> URL: https://issues.apache.org/jira/browse/SSHD-1162
> Project: MINA SSHD
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 2.7.1, 2.8.0
>
>
> If not, the Buffer.flip() methods can be built using JDK 11 methods and cause
> linking errors when run at JDK 8.
--
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] [Assigned] (SSHD-1162) Make sure the project is built using a 1.8
[ https://issues.apache.org/jira/browse/SSHD-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1162: - Assignee: Guillaume Nodet > Make sure the project is built using a 1.8 > - > > Key: SSHD-1162 > URL: https://issues.apache.org/jira/browse/SSHD-1162 > Project: MINA SSHD > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Blocker > Fix For: 2.7.1, 2.8.0 > > > If not, the Buffer.flip() methods can be built using JDK 11 methods and cause > linking errors when run at JDK 8. -- 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-1169) Sftp Server throughput is lagging for concurrent threads
[ https://issues.apache.org/jira/browse/SSHD-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347128#comment-17347128 ] Guillaume Nodet commented on SSHD-1169: --- It would help a lot if you could set up a unit test that we could run in our build to actually replicate and debug the problem. > Sftp Server throughput is lagging for concurrent threads > > > Key: SSHD-1169 > URL: https://issues.apache.org/jira/browse/SSHD-1169 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Susmit Sarkar >Priority: Blocker > Attachments: image-2021-05-18-20-10-43-416.png, > image-2021-05-18-22-37-08-832.png > > > Hello Team, > We are seeing a considerably low throughput for large-sized file (100Mb sized > file during concurrent execution) > We did some load testing and the throughputs sometimes increase (when we do a > VM reboot for 1st run) and sometimes its pretty low compare to commercial > servers > > *2000 cycle runs | 20 concurrent threads | 100mb files == Throughput is 0.94 > documents per seconds* > For a commercial server (like Maverick), it's around 1.17 documents per > second. > Now if we do a server reboot and re-execute the test then the throughput > increases by leaps and bounds > *2000 cycle runs | 20 concurrent threads | 100 MB files == Throughput is 1.90 > documents per seconds (More than 100 percent)* > *cycle means 100 MB file upload times, 2000 means 2000times*100 MB which got > distributed by 20 concurrent sftp sessions* > I am using IO Factory as NIO2, and below are the combinations for different > NIO worker threads > !image-2021-05-18-22-37-08-832.png! > We are pretty confused and need help. For small files, Apache performed very > well the throughput was 30 percent better than Maverick, but for large files, > we are seeing these issues sometimes (mostly with reboot it performs good, > but after that run its starts lagging) > nio-workers ===> *varies from the chart above* > max-auth-requests ===> 3 > Compression ===> NONE > max-concurrent-sessions ===> 2147483647 > packet-size ===> 65536 > idle-timeout ===> 30 > server-identification ===> SFTP Server > window-size ===> 4194304 > we are setting currently all this properties to *SshServer*, is there any > performance tuning parameter can be used? > -- 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-1162) Make sure the project is built using a 1.8
Guillaume Nodet created SSHD-1162: - Summary: Make sure the project is built using a 1.8 Key: SSHD-1162 URL: https://issues.apache.org/jira/browse/SSHD-1162 Project: MINA SSHD Issue Type: Task Reporter: Guillaume Nodet Fix For: 2.7.1, 2.8.0 If not, the Buffer.flip() methods can be built using JDK 11 methods and cause linking errors when run at JDK 8. -- 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-525) Add support for "posix-ren...@openssh.com" SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-525. -- Resolution: Fixed > Add support for "posix-ren...@openssh.com" SFTP extension > - > > Key: SSHD-525 > URL: https://issues.apache.org/jira/browse/SSHD-525 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 2.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.28=text/x-cvsweb-markup -- 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-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-981: - Fix Version/s: (was: 2.7.0) > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > > This extension has been specified by [RFC 8308 - section > 3.3|https://tools.ietf.org/html/rfc8308#section-3.3] -- 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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1145.
---
Fix Version/s: 2.7.0
Assignee: Guillaume Nodet
Resolution: Fixed
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1029) Support native PTY in SSH server
[ https://issues.apache.org/jira/browse/SSHD-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1029: -- Priority: Minor (was: Major) > Support native PTY in SSH server > > > Key: SSHD-1029 > URL: https://issues.apache.org/jira/browse/SSHD-1029 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Minor > > In order to correctly integrate with native shells, we need to open a PTY and > launch the command redirecting the streams from/to the pty. -- 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-525) Add support for "posix-ren...@openssh.com" SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-525: - Fix Version/s: 2.7.0 > Add support for "posix-ren...@openssh.com" SFTP extension > - > > Key: SSHD-525 > URL: https://issues.apache.org/jira/browse/SSHD-525 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Priority: Minor > Fix For: 2.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.28=text/x-cvsweb-markup -- 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] [Assigned] (SSHD-525) Add support for "posix-ren...@openssh.com" SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-525: Assignee: Guillaume Nodet > Add support for "posix-ren...@openssh.com" SFTP extension > - > > Key: SSHD-525 > URL: https://issues.apache.org/jira/browse/SSHD-525 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 2.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > See > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.28=text/x-cvsweb-markup -- 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-1160) SshClient does not cleanup resources
[ https://issues.apache.org/jira/browse/SSHD-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341778#comment-17341778 ] Guillaume Nodet commented on SSHD-1160: --- Could you please provide a simple test to reproduce the problem ? > SshClient does not cleanup resources > > > Key: SSHD-1160 > URL: https://issues.apache.org/jira/browse/SSHD-1160 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: RedHat Linux 7 > Java 1.8.0_281 >Reporter: Catalin Merfu >Priority: Major > > # SshClient.setUpDefaultClient().start() opens 100+ pipes and anons > Checked with ls -l /proc//fs > # client.stop() does not close the fds at (1) -- 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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313169#comment-17313169
]
Guillaume Nodet commented on SSHD-1145:
---
Actually, I wonder if it'd be better to flag the
{{ThreadUtils.resolveDefaultClassLoader}} method as _deprecated_ in favour of
{{ThreadUtils.resolveDefaultClassLoaders}} and
{{ThreadUtils.resolveDefaultClass}} in addition to your suggested change.
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313165#comment-17313165
]
Guillaume Nodet commented on SSHD-1145:
---
[~ggrzybek] It looks good to me. Do you want to provide a PR ?
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1152) Some warnings are never logged
[
https://issues.apache.org/jira/browse/SSHD-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1152.
---
Fix Version/s: 2.6.1
Resolution: Fixed
Thx, I've fixed it with
https://github.com/apache/mina-sshd/commit/ea57983ca77717f22170db40b3048e005719e4fd
> Some warnings are never logged
> --
>
> Key: SSHD-1152
> URL: https://issues.apache.org/jira/browse/SSHD-1152
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.1
>
>
> Some Warnings that are output via a certain warn method in LoggingUtils don't
> make it into the log files.
> Example: ServerUserAuthService#handleUserAuthRequestMessage
> {code}
> } catch (Exception e) {
> warn("handleUserAuthRequestMessage({}) Failed ({}) to
> authenticate using factory method={}: {}",
> session, e.getClass().getSimpleName(), method,
> e.getMessage(), e);
> }
> {code}
> There is a bug in the implementation that checks for "log.isDebugEnabled()"
> in all cases:
> {code}
> public static void warn(Logger log, String message, Object o1, Object o2,
> Object o3, Object o4, Throwable t) {
> if (log.isDebugEnabled() && t != null) {
> log.warn(message, o1, o2, o3, o4, t);
> } else if (log.isDebugEnabled()) {
> log.warn(message, o1, o2, o3, o4);
> }
> }
> {code}
--
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] [Assigned] (SSHD-1152) Some warnings are never logged
[
https://issues.apache.org/jira/browse/SSHD-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1152:
-
Assignee: Guillaume Nodet
> Some warnings are never logged
> --
>
> Key: SSHD-1152
> URL: https://issues.apache.org/jira/browse/SSHD-1152
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
>Assignee: Guillaume Nodet
>Priority: Major
>
> Some Warnings that are output via a certain warn method in LoggingUtils don't
> make it into the log files.
> Example: ServerUserAuthService#handleUserAuthRequestMessage
> {code}
> } catch (Exception e) {
> warn("handleUserAuthRequestMessage({}) Failed ({}) to
> authenticate using factory method={}: {}",
> session, e.getClass().getSimpleName(), method,
> e.getMessage(), e);
> }
> {code}
> There is a bug in the implementation that checks for "log.isDebugEnabled()"
> in all cases:
> {code}
> public static void warn(Logger log, String message, Object o1, Object o2,
> Object o3, Object o4, Throwable t) {
> if (log.isDebugEnabled() && t != null) {
> log.warn(message, o1, o2, o3, o4, t);
> } else if (log.isDebugEnabled()) {
> log.warn(message, o1, o2, o3, o4);
> }
> }
> {code}
--
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-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1146.
---
Resolution: Fixed
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.7.0
>
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1146:
--
Fix Version/s: (was: 2.6.1)
2.7.0
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.7.0
>
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303344#comment-17303344
]
Guillaume Nodet commented on SSHD-1145:
---
Though, if {{org.osgi.framework.bootdelegation}} is correctly set with the
{{net.i2p.crypto.addsa.*}} value, shouldn't the class load work ?
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303340#comment-17303340
]
Guillaume Nodet commented on SSHD-1145:
---
Ah, that's really bad. This should be fixed too then.
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1145) EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
[
https://issues.apache.org/jira/browse/SSHD-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303331#comment-17303331
]
Guillaume Nodet commented on SSHD-1145:
---
The Karaf documentation for security providers is available at
https://github.com/apache/karaf/blob/master/manual/src/main/asciidoc/user-guide/security.adoc#security-providers.
This could be a good way to avoid class loader issues...
> EdDSASecurityProviderRegistrar#isSupported() should check more classloaders
> ---
>
> Key: SSHD-1145
> URL: https://issues.apache.org/jira/browse/SSHD-1145
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519
> for server key.
> EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
> checked in a way that is not correct (and not only in OSGi environment).
> It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
> actually for all methods that use
> {{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class)}}.
> {{resolveDefaultClassLoader()}} method result is a classloader which is
> checked for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but
> the check result is cached statically. The problem is that if TCCL is used
> (which is generally not defined in OSGi) it may be a false negative.
> More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL
> that _sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
> If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
> started - e.g., through OSGi blueprint) - the first one who calls
> {{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
> _wins_.
> I'll work on a way to check more classloaders in search for given
> provider/registrar and send a PR soon.
--
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-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1146:
--
Fix Version/s: 2.6.1
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.1
>
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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] [Assigned] (SSHD-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1146:
-
Assignee: Guillaume Nodet
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303254#comment-17303254
]
Guillaume Nodet edited comment on SSHD-1146 at 3/17/21, 10:02 AM:
--
The following patch seems to add back the needed imports:
{code}
diff --git a/pom.xml b/pom.xml
index ed5263d5..20258d23 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1421,7 +1421,7 @@
-
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))"
+
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))",*
*;-noimport:=true
pom
{code}
This results in the following imports for {{sshd-osgi}}
{code}
Import-Package: javax.crypto,javax.crypto.interfaces,javax.crypto.spec,j
avax.management,javax.security.auth,javax.security.auth.callback,javax.
security.auth.login,net.i2p.crypto.eddsa;resolution:=optional;version="
[0.3,1)",net.i2p.crypto.eddsa.math;resolution:=optional,net.i2p.crypto.
eddsa.spec;resolution:=optional;version="[0.3,1)",org.apache.tomcat.jni
;resolution:=optional,org.bouncycastle.crypto.prng;resolution:=optional
;version="[1.68,2)",org.bouncycastle.openssl;resolution:=optional;versi
on="[1.68,2)",org.bouncycastle.openssl.jcajce;resolution:=optional;vers
ion="[1.68,2)",org.ietf.jgss,org.slf4j;version="[1.7,2)",org.slf4j.even
t;version="[1.7,2)",org.slf4j.helpers;version="[1.7,2)"
{code}
was (Author: gnt):
The following patch seems to add back the needed imports:
{code}
diff --git a/pom.xml b/pom.xml
index ed5263d5..20258d23 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1421,7 +1421,7 @@
-
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))"
+
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))",*
*;-noimport:=true
pom
{code}
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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-1146) Missing Import-Package header in sshd-osgi-2.6.0
[
https://issues.apache.org/jira/browse/SSHD-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303254#comment-17303254
]
Guillaume Nodet commented on SSHD-1146:
---
The following patch seems to add back the needed imports:
{code}
diff --git a/pom.xml b/pom.xml
index ed5263d5..20258d23 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1421,7 +1421,7 @@
-
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))"
+
org.apache.sshd*;version="[$(version;==;${sshd.osgi.version.clean}),$(version;=+;${sshd.osgi.version.clean}))",*
*;-noimport:=true
pom
{code}
> Missing Import-Package header in sshd-osgi-2.6.0
>
>
> Key: SSHD-1146
> URL: https://issues.apache.org/jira/browse/SSHD-1146
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Major
> Attachments: manifest-summary-2.5.1.txt, manifest-summary.txt
>
>
> After SSHD-1092, where sshd-core and sshd-common (and other modules) lost
> their OSGi manifests, sshd-core which repackages them, no longer provides any
> {{Import-Package}} headers. Effectively this makes sshd-osgi-2.6.0 unusable
> in OSGi env.
> Remember that e.g., Karaf's {{ssh}} features contains not only sshd-osgi
> bundles (now at version 2.5.1):
> {code:xml}
> start-level="30">mvn:org.apache.sshd/sshd-osgi/${sshd.version}
> mvn:org.apache.sshd/sshd-scp/${sshd.version}
> start-level="30">mvn:org.apache.sshd/sshd-sftp/${sshd.version}
> {code}
> To better look and compare OSGi headers, please have a look at
> https://ops4j1.jira.com/wiki/spaces/TOOLS/pages/412549134/OSGi+Report+Maven+Plugin
> - you don't have to create special maven module (as we do with Pax
> projects), you can simply invoke:
> {noformat}
> mvn install
> org.ops4j.tools.maven:osgi-report-maven-plugin:0.1.1:manifest-summary
> {noformat}
> inside {{sshd-osgi}} module and you'll get something like
> [^manifest-summary.txt] - it is easy to compare it with similar summary
> created for different version, like [^manifest-summary-2.5.1.txt].
--
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-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303194#comment-17303194
]
Guillaume Nodet edited comment on SSHD-1092 at 3/17/21, 8:40 AM:
-
[~ggrzybek] can you open a new jira please, I'll commit a fix
was (Author: gnt):
[~ggrzybek]can you open a new jira please, I'll commit a fix
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303194#comment-17303194
]
Guillaume Nodet commented on SSHD-1092:
---
[~ggrzybek]can you open a new jira please, I'll commit a fix
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17295902#comment-17295902
]
Guillaume Nodet commented on SSHD-1118:
---
Right. Though, I think clients are supposed to return an
{{SSH_MSG_UNIMPLEMENTED}} response when they receive an unknown/unsupported
request, so that should be quite safe even if clients do not support it. It
would have to be verified, but enabling extensions on the server side by
default would be nice if that's the case.
In any case, having the ability to configure which extensions the server would
send automatically would be required.
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17295892#comment-17295892
]
Guillaume Nodet commented on SSHD-1118:
---
I think implementing the {{server-sig-algs}} on the server side would help in
this case, as the clients would not be forced to add an explicit
{{-oPubkeyAcceptedKeyTypes=rsa-sha2-512}} in order to connect to the SSHD
server.
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1029) Support native PTY in SSH server
[ https://issues.apache.org/jira/browse/SSHD-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1029: -- Fix Version/s: (was: 2.7.0) > Support native PTY in SSH server > > > Key: SSHD-1029 > URL: https://issues.apache.org/jira/browse/SSHD-1029 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > > In order to correctly integrate with native shells, we need to open a PTY and > launch the command redirecting the streams from/to the pty. -- 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-1091) Java Module support
[ https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1091: -- Fix Version/s: 3.0.0 > Java Module support > --- > > Key: SSHD-1091 > URL: https://issues.apache.org/jira/browse/SSHD-1091 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Gili >Priority: Major > Labels: important > Fix For: 3.0.0 > > > Please use the mechanism found at > https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108 > to build multirelease JAR that will provide module-info.java for users of > Java 9 and newer. > The current JAR triggers many problems for users of Java Modules and in fact > cannot be used at all in its current state due to > https://issues.apache.org/jira/browse/MCOMPILER-436 > This might be a bug in the Maven Compiler plugin but I suspect that > ultimately it will a problem with the library itself. For example, I noticed > that Apache Mina (which this library depends on) has split packages. Split > packages are incompatible with Java Modules. -- 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-1091) Java Module support
[
https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17235289#comment-17235289
]
Guillaume Nodet commented on SSHD-1091:
---
I think the packages are already split in a logical manner: their name do
reflect where they belong. That's why we should split according to those
package names. The current split has proven to be difficult both from a
technical POV (it introduces split packages) and semantically (I'm not the only
one to think it is not intuitive), so I think we should go back on that and
keep:
- {{sshd-common}} for all {{org.apache.ssh.common.*}} packages
- {{ssd-client}} for all {{org.apache.ssh.client.*}} packages
- {{ssd-server}} for all {{org.apache.ssh.server.*}} packages
- {{ssd-agent}} for all {{org.apache.ssh.agent.*}} packages
- {{sshd-core}} : do not contain any packages, but contains all the tests and
has dependencies on all the above for backward compatibility
This will have the benefits of :
- remove the split packages (which is the original problem)
- keeping mostly backward compatible (i.e. the packages do not change),
people depending on {{sshd-core}} will continue without any problem
- align semantic / package naming
So in terms of actions to do, this means:
* create a {{ssh-client}} and {{sshd-server}} packages
* move packages from {{sshd-core}} to either {{sshd-common}}, {{sshd-client}}
or {{ssd-server}}
* fix everything ;)
> Java Module support
> ---
>
> Key: SSHD-1091
> URL: https://issues.apache.org/jira/browse/SSHD-1091
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.5.1
>Reporter: Gili
>Priority: Major
> Labels: important
>
> Please use the mechanism found at
> https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108
> to build multirelease JAR that will provide module-info.java for users of
> Java 9 and newer.
> The current JAR triggers many problems for users of Java Modules and in fact
> cannot be used at all in its current state due to
> https://issues.apache.org/jira/browse/MCOMPILER-436
> This might be a bug in the Maven Compiler plugin but I suspect that
> ultimately it will a problem with the library itself. For example, I noticed
> that Apache Mina (which this library depends on) has split packages. Split
> packages are incompatible with Java Modules.
--
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-1091) Java Module support
[ https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234031#comment-17234031 ] Guillaume Nodet commented on SSHD-1091: --- [~lgoldstein] Imho, sshd-common should keep only the o.a.sshd.common packages. The o.a.sshd.client and o.a.sshd.server packages from sshd-common _and_ sshd-core should go respectively in ssd-client and ssd-server. [~cowwoc] We could rename sshd-core to sshd-runtime if that's more intuitive, not sure though... [~mattsicker] I think what [~cowwoc] meant was related to the split between sshd-common and sshd-core, not the split from sshd-core to sshd-core/sshd-client/sshd-server. > Java Module support > --- > > Key: SSHD-1091 > URL: https://issues.apache.org/jira/browse/SSHD-1091 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Gili >Priority: Major > Labels: important > > Please use the mechanism found at > https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108 > to build multirelease JAR that will provide module-info.java for users of > Java 9 and newer. > The current JAR triggers many problems for users of Java Modules and in fact > cannot be used at all in its current state due to > https://issues.apache.org/jira/browse/MCOMPILER-436 > This might be a bug in the Maven Compiler plugin but I suspect that > ultimately it will a problem with the library itself. For example, I noticed > that Apache Mina (which this library depends on) has split packages. Split > packages are incompatible with Java Modules. -- 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-1091) Java Module support
[ https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17233514#comment-17233514 ] Guillaume Nodet commented on SSHD-1091: --- [~lgoldstein] I know, we already had this discussion. Though I don't see the benefit of the current split. Unit tests can be setup with a server/client for the classes that require it and without for those that do not. If we're going to a more modular build, I think we should split between common / client / server in addition to the current split between non-io / io related classes. That way, users would be able to use the client without requiring the server and the opposite. And if we're going for a 3.0 version, we should think on how to reduce the footprint a bit as the sshd-osgi (which contains client + server) is almost 1.6M, which is _a lot._ > Java Module support > --- > > Key: SSHD-1091 > URL: https://issues.apache.org/jira/browse/SSHD-1091 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Gili >Priority: Major > Labels: important > > Please use the mechanism found at > https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108 > to build multirelease JAR that will provide module-info.java for users of > Java 9 and newer. > The current JAR triggers many problems for users of Java Modules and in fact > cannot be used at all in its current state due to > https://issues.apache.org/jira/browse/MCOMPILER-436 > This might be a bug in the Maven Compiler plugin but I suspect that > ultimately it will a problem with the library itself. For example, I noticed > that Apache Mina (which this library depends on) has split packages. Split > packages are incompatible with Java Modules. -- 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-1029) Support native PTY in SSH server
[ https://issues.apache.org/jira/browse/SSHD-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1029: -- Fix Version/s: (was: 2.6.0) 2.7.0 > Support native PTY in SSH server > > > Key: SSHD-1029 > URL: https://issues.apache.org/jira/browse/SSHD-1029 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > Fix For: 2.7.0 > > > In order to correctly integrate with native shells, we need to open a PTY and > launch the command redirecting the streams from/to the pty. -- 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-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-981: - Fix Version/s: (was: 2.6.0) 2.7.0 > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.7.0 > > > This extension has been specified by [https://tools.ietf.org/html/rfc8308] -- 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-1091) Java Module support
[ https://issues.apache.org/jira/browse/SSHD-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230963#comment-17230963 ] Guillaume Nodet commented on SSHD-1091: --- It seems to me the easiest way would be to merge sshd-common back into sshd-core. That was the case before, and the split has always been a bit hazy (it is quite difficult to understand which class should go in which module) imho. I think a better split (if needed) would be o.a.sshd.common / o.a.sshd.client / o.a.sshd.server which would allow using the client and server parts with less code than today. > Java Module support > --- > > Key: SSHD-1091 > URL: https://issues.apache.org/jira/browse/SSHD-1091 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.5.1 >Reporter: Gili >Priority: Major > Labels: important > > Please use the mechanism found at > https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108 > to build multirelease JAR that will provide module-info.java for users of > Java 9 and newer. > The current JAR triggers many problems for users of Java Modules and in fact > cannot be used at all in its current state due to > https://issues.apache.org/jira/browse/MCOMPILER-436 > This might be a bug in the Maven Compiler plugin but I suspect that > ultimately it will a problem with the library itself. For example, I noticed > that Apache Mina (which this library depends on) has split packages. Split > packages are incompatible with Java Modules. -- 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-1102) Support filters in sftp directory streams
Guillaume Nodet created SSHD-1102: - Summary: Support filters in sftp directory streams Key: SSHD-1102 URL: https://issues.apache.org/jira/browse/SSHD-1102 Project: MINA SSHD Issue Type: Task Reporter: Guillaume Nodet The SftpFileSystemProvider does not support filters in directory streams https://github.com/apache/mina-sshd/blob/master/sshd-sftp/src/main/java/org/apache/sshd/sftp/client/fs/SftpFileSystemProvider.java#L521-L523 -- 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-1029) Support native PTY in SSH server
[ https://issues.apache.org/jira/browse/SSHD-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223034#comment-17223034 ] Guillaume Nodet commented on SSHD-1029: --- The [https://blog.javaforge.net/post/68495259926/embedded-ssh-daemon-and-remote-shell-for-java-applicatio] is really about integrating with a java shell, which already works perfectly. This issue is about integrating with a native shell, such as bash or zsh, which is a bit more complicated because the native shell will need a pseudo-terminal created by the OS and that's where the problems are... > Support native PTY in SSH server > > > Key: SSHD-1029 > URL: https://issues.apache.org/jira/browse/SSHD-1029 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > Fix For: 2.6.0 > > > In order to correctly integrate with native shells, we need to open a PTY and > launch the command redirecting the streams from/to the pty. -- 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-1093) Help on permissions on SCP and SFTP operations
[ https://issues.apache.org/jira/browse/SSHD-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218548#comment-17218548 ] Guillaume Nodet commented on SSHD-1093: --- For SFTP, you can implement either a custom [https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#sftpfilesystemaccessor] or a custom [https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#sftpeventlistener,] depending on your exact needs. For SCP, you can implement a [https://github.com/apache/mina-sshd/blob/master/docs/scp.md#scptransfereventlistener.] You can also provide custom ScpFileOpener and ScpTargetStreamResolver... > Help on permissions on SCP and SFTP operations > -- > > Key: SSHD-1093 > URL: https://issues.apache.org/jira/browse/SSHD-1093 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Blocker > Labels: SCP, SFTP, mina > > We were doing a proof of concept and we are stuck. The use case is before any > file operations I need to check whether the user in session is having > permissions to carry on the operations, along with that we have a logic to > check whether the command is valid or not for both SCP and SFTP. > > The 2 pre-operations I am not able to perform and I am a bit confused, your > guidance and help will be highly appreciated. > > I am sharing the git location so it helps you guys see the code, it's a very > small maven project with FileSystem. > > We are not able to understand where should we implement the hook to achieve > the above use case > > Thank you again > > [https://github.com/Susmit07/sftp-poc] -- 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-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-1092.
---
Fix Version/s: 2.6.0
Resolution: Fixed
Fixed by
https://github.com/apache/mina-sshd/commit/b38674a4f27a673ee88670914866765b862f5c4d
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 2.6.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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] [Reopened] (SSHD-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reopened SSHD-1092:
---
My bad, I'll revert and remove the metadata for the two bundles instead.
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated SSHD-1092:
--
Summary: Keep OSGi metadata only for sshd-osgi (was: Split package causing
use conflict in OSGi)
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1092) Keep OSGi metadata only for sshd-osgi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217396#comment-17217396
]
Guillaume Nodet commented on SSHD-1092:
---
Fixed in
https://github.com/apache/mina-sshd/commit/a06cc51cf1abed7f20aecc781d7bfd61e6a8537f
> Keep OSGi metadata only for sshd-osgi
> -
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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] [Assigned] (SSHD-1092) Split package causing use conflict in OSGi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-1092:
-
Assignee: Guillaume Nodet
> Split package causing use conflict in OSGi
> --
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Assignee: Guillaume Nodet
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1092) Split package causing use conflict in OSGi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217391#comment-17217391
]
Guillaume Nodet commented on SSHD-1092:
---
Removing the metadata from the other jars is the best way imho, leaving it will
cause more trouble.
> Split package causing use conflict in OSGi
> --
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1092) Split package causing use conflict in OSGi
[
https://issues.apache.org/jira/browse/SSHD-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214800#comment-17214800
]
Guillaume Nodet commented on SSHD-1092:
---
Fwiw, there is an sshd-osgi artefact which has OSGi metadata and avoid split
packages.
> Split package causing use conflict in OSGi
> --
>
> Key: SSHD-1092
> URL: https://issues.apache.org/jira/browse/SSHD-1092
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: Windows 10
> Eclipse 2020-09
> Bndtools 5.3.0 snapshot
>Reporter: Fr Jeremy Krieg
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I started trying to use the sshd modules in an OSGi project.
> I discovered that there is a split package - the package
> {{org.apache.sshd.common}} is present and exported in both
> {{org.apache.sshd.core}} and {{org.apache.sshd.common}}. Core depends on the
> package {{org.apache.sshd.client.hosts}}, which has a uses constraint on the
> {{org.apache.sshd.common}} package. Because this package is exported by both
> the core and client packages, the resolver is unable to resolve the core
> bundle.
>
--
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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202046#comment-17202046
]
Guillaume Nodet commented on SSHD-1086:
---
You set the {{basedir}} to a string, that can't work.
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Critical
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202020#comment-17202020 ] Guillaume Nodet commented on SSHD-1086: --- How is the scanner is related to the remote SFTP system in your code ? > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Critical > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1086. --- Resolution: Not A Problem Please have a look at existing tests / examples and start from those : [https://github.com/apache/mina-sshd/blob/5cbae28a42c478c052ade11d0fc3b84d4ee2f720/sshd-sftp/src/test/java/org/apache/sshd/sftp/client/fs/SftpFileSystemTest.java] or [ https://github.com/apache/mina-sshd/blob/5cbae28a42c478c052ade11d0fc3b84d4ee2f720/sshd-sftp/src/test/java/org/apache/sshd/sftp/client/SftpPerformanceTest.java|https://github.com/apache/mina-sshd/blob/5cbae28a42c478c052ade11d0fc3b84d4ee2f720/sshd-sftp/src/test/java/org/apache/sshd/sftp/client/SftpPerformanceTest.java] When you actually have a real problem, instead of just not understanding what to do and missing steps and misconfiguring things, we might be able to help you... > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Critical > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201496#comment-17201496
]
Guillaume Nodet commented on SSHD-1086:
---
Right, you do not have to use the {{FileSystem}} api and you can just use the
{{SftpClient}} api if you want. It's up to you.
But if you think you know better, please don't waste our time asking for
advices.
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Critical
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1088) How to run ls command remotly
[ https://issues.apache.org/jira/browse/SSHD-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1088. --- Resolution: Not A Problem Please read the documentation at https://github.com/apache/mina-sshd/blob/master/docs/sftp.md > How to run ls command remotly > - > > Key: SSHD-1088 > URL: https://issues.apache.org/jira/browse/SSHD-1088 > Project: MINA SSHD > Issue Type: Bug >Reporter: Chhaya >Priority: Major > > How to run ls command remotly. > Please give me some example. -- 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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201478#comment-17201478 ] Guillaume Nodet edited comment on SSHD-1086 at 9/24/20, 12:06 PM: -- Please read the documentation about how to setup the `ClientSession`. You're missing the authentication part. https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md was (Author: gnt): Please read the documentation about how to setup the `ClientSession`. You're missing the authentication part. > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Critical > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201478#comment-17201478 ] Guillaume Nodet commented on SSHD-1086: --- Please read the documentation about how to setup the `ClientSession`. You're missing the authentication part. > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Critical > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201380#comment-17201380
]
Guillaume Nodet commented on SSHD-1086:
---
*Do not create the {{SftpClient, but pass the }}{{ClientSession}}{{ which is
used to create the SftpClient to create the file system instead.}}*
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Critical
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200742#comment-17200742
]
Guillaume Nodet commented on SSHD-1086:
---
*Do not create the {{SftpClient}}*, but pass the {{ClientSession}} instead.
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Major
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200737#comment-17200737 ] Guillaume Nodet commented on SSHD-1086: --- Use the latest SSHD version, it has been added a 18 months ago. > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Major > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200696#comment-17200696
]
Guillaume Nodet edited comment on SSHD-1086 at 9/23/20, 9:49 AM:
-
The problem is that {{new File(fullPathNoEndSeparator)}} will return a local
file. If you want to scan the remote file system using SFTP, you need to use :
{code:java}
FileSystem fs = SftpClientFactory.instance().createSftpFileSystem(session);
...
ds.setBaseDir(fs.getPath(fullPathNoEndSeparator);{code}
No need to create the {{SftpClient}}, just use an {{ClientSession}}.
was (Author: gnt):
I think {{(*new* File(fullPathNoEndSeparator)}} will return a local file. If
you want to scan the remote file system using SFTP, you need to use :
{code:java}
FileSystem fs = SftpClientFactory.instance().createSftpFileSystem(session);
...
ds.setBaseDir(fs.getPath(fullPathNoEndSeparator);{code}
No need to create the {{SftpClient}}, just use an {{ClientSession}}.
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Major
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1086) Base dir doesn’t exist issue
[
https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200696#comment-17200696
]
Guillaume Nodet commented on SSHD-1086:
---
I think {{(*new* File(fullPathNoEndSeparator)}} will return a local file. If
you want to scan the remote file system using SFTP, you need to use :
{code:java}
FileSystem fs = SftpClientFactory.instance().createSftpFileSystem(session);
...
ds.setBaseDir(fs.getPath(fullPathNoEndSeparator);{code}
No need to create the {{SftpClient}}, just use an {{ClientSession}}.
> Base dir doesn’t exist issue
>
>
> Key: SSHD-1086
> URL: https://issues.apache.org/jira/browse/SSHD-1086
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Netram
>Priority: Major
> Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I am getting base dir doesn’t exist error message.
> This error is throwing from ds.scan() method.
> This is working in local env not working in remote server.
> Please see the attached code.
--
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-1085) channel.waitFor() get stuck when run reboot command
[
https://issues.apache.org/jira/browse/SSHD-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200678#comment-17200678
]
Guillaume Nodet commented on SSHD-1085:
---
Maybe we could set up a unit test for that using {{GenericContainer}} as done
in the
[{{SftpPerformanceTest}}|https://github.com/apache/mina-sshd/blob/master/sshd-sftp/src/test/java/org/apache/sshd/sftp/client/SftpPerformanceTest.java]
unit test ?
> channel.waitFor() get stuck when run reboot command
> ---
>
> Key: SSHD-1085
> URL: https://issues.apache.org/jira/browse/SSHD-1085
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: linux
>Reporter: min yun law
>Priority: Major
>
> Trying to run linux command "reboot" by mina sshd to remote node, the node is
> in reboot, but the ClientChannel object still keep open, not in closed
> status, Here is the logic code in my project:
>
> {code:java}
> String command = "reboot";
> ChannelExec channel = clientSession.createExecChannel(command);
> if(!channel.isClosed())
> {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ByteArrayOutputStream err = new ByteArrayOutputStream(); channel.setOut(out);
> channel.setErr(err);
> channel.open().await(); //this passed
> //follow call will cause stuck
> Collection waitMask =
> channel.waitFor(REMOTE_COMMAND_WAIT_EVENTS, 0L);
> String outputStr = new String(out.toByteArray(), StandardCharsets.UTF_8);
> //some case this will throw runtime exception
> int exitStatus = channel.getExitStatus();
> }
>
> {code}
>
> So why the ChannelExec cannot get the correct channel status when remote node
> is rebooting?
>
>
>
--
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-1086) Base dir doesn’t exist issue
[ https://issues.apache.org/jira/browse/SSHD-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200676#comment-17200676 ] Guillaume Nodet commented on SSHD-1086: --- Please paste the code and not a screenshot. Also paste the exception you get. > Base dir doesn’t exist issue > > > Key: SSHD-1086 > URL: https://issues.apache.org/jira/browse/SSHD-1086 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Major > Attachments: 309002D7-B870-410D-B4A0-A1683166298A.jpeg > > Original Estimate: 2h > Remaining Estimate: 2h > > I am getting base dir doesn’t exist error message. > This error is throwing from ds.scan() method. > This is working in local env not working in remote server. > Please see the attached code. -- 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] [Closed] (SSHD-1087) How to use ls command
[ https://issues.apache.org/jira/browse/SSHD-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed SSHD-1087. - Resolution: Fixed Please don't ask the same question via 4 different channels (private email, dev@, users@, jira). One between users@ or a jira issue is enough. > How to use ls command > -- > > Key: SSHD-1087 > URL: https://issues.apache.org/jira/browse/SSHD-1087 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: Netram >Priority: Major > > How to use ls command with Sftpclient. > Want to get data for > dir/dir1*/Test.txt, > dir/dir?/Text.txt -- 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-1066) Support multiple local interfaces in PortForwarding
[
https://issues.apache.org/jira/browse/SSHD-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200664#comment-17200664
]
Guillaume Nodet commented on SSHD-1066:
---
I've pushed a PR with a unit test
https://github.com/apache/mina-sshd/pull/170/commits/89bb372b69ef4f20929e42b9af2f013790bf2f76
> Support multiple local interfaces in PortForwarding
> ---
>
> Key: SSHD-1066
> URL: https://issues.apache.org/jira/browse/SSHD-1066
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.5.1
>Reporter: Guillermo Grandes
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to listen in same port on 2 IPs of same machine, _multihomed_, the
> equivalent in openssh is:
> {noformat}
> # ssh -L 127.0.0.2:8080:test.javastack.org:80 -L
> 127.0.0.3:8080:test.javastack.org:80 test-sshd@server -N
> # sudo netstat -lntp | grep :8080
> tcp 0 0 127.0.0.3:8080 0.0.0.0:* LISTEN 2650/ssh
> tcp 0 0 127.0.0.2:8080 0.0.0.0:* LISTEN 2650/ssh
> {noformat}
> Sample code to reproduce the test case:
> {code:java}
> public static final int DEFAULT_TIMEOUT = 1;
> public static void test(final String username, final String password,
> final String host, final int port)
> throws IOException {
> boolean testLocal = true;
> try (SshClient client = SshClient.setUpDefaultClient()) {
>
> client.setServerKeyVerifier(AcceptAllServerKeyVerifier.INSTANCE);
> client.start();
> try {
> ConnectFuture connect =
> client.connect(username, host, port);
> connect.await(DEFAULT_TIMEOUT);
> ClientSession session =
> connect.getClientSession();
> session.addPasswordIdentity(password);
> session.auth().verify(DEFAULT_TIMEOUT);
> if (testLocal) {
> System.out.println("==
> Local 1 ==");
> ExplicitPortForwardingTracker
> localTracker1 = session.createLocalPortForwardingTracker(
> new
> SshdSocketAddress("127.0.0.2", 8080),
> new
> SshdSocketAddress("test.javastack.org", 80));
> sleep(1000);
>
> System.out.println("LocalPortForwarding: " //
> +
> localTracker1.getLocalAddress() + " -> " //
> +
> localTracker1.getRemoteAddress());
> SshdSocketAddress localSocketAddress1 =
> localTracker1.getLocalAddress();
> if (localSocketAddress1 != null) {
> Proxy proxy = new
> Proxy(Proxy.Type.HTTP,
> new
> InetSocketAddress(localSocketAddress1.getHostName(), //
>
> localSocketAddress1.getPort()));
> testRemoteURL(proxy,
> "http://test.javastack.org/;);
> }
> System.out.println("==
> Local 2 ==");
> ExplicitPortForwardingTracker
> localTracker2 = session.createLocalPortForwardingTracker(
> new
> SshdSocketAddress("127.0.0.3", 8080),
> new
> SshdSocketAddress("test.javastack.org", 80));
> sleep(1000);
>
> System.out.println("LocalPortForwarding: " //
> +
> localTracker2.getLocalAddress() + " -> " //
> +
> localTracker2.getRemoteAddress());
> SshdSocketAddress localSocketAddress2 =
> localTracker2.getLocalAddress();
> if (localSocketAddress2 != null) {
> Proxy proxy = new
> Proxy(Proxy.Type.HTTP,
> new
> InetSocketAddress(localSocketAddress2.getHostName(), //
>
> localSocketAddress2.getPort()));
>
