[jira] [Updated] (SSHD-1337) New Attacks on SSH Channel Integrity
[ https://issues.apache.org/jira/browse/SSHD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1337: - Description: {quote}We [1] are security researchers from the Ruhr University Bochum, and have discovered new attacks on the SSH channel integrity, which we want to disclose to you. You can find the draft version of our research paper, which we submitted to the USENIX Security conference, in [2]. Please treat it confidential until public disclosure, which is currently planned for 18th of December 2023 (2023-12-18). Prefix truncation attack on BPP: By manipulating sequence numbers during the handshake, an attacker can remove the initial messages on the secure channel, without causing a MAC failure. The vulnerable cipher modes are ChaCha20-Poly1305 (chacha20-poly1...@openssh.com) and Encrypt-then-MAC (-e...@openssh.com MAC algorithms). Practical Exploits and Impact: With channel integrity broken, we also show several exploits. An extension negotiation downgrade attack undermines channel security by removing the extension info message, and works against all compliant implementations. For example, an attacker can disable the ping extension and thus disable the new countermeasure in OpenSSH 9.5 against keystroke timing attacks. Two other exploits against AsyncSSH are even more severe, but additionally rely on implementation flaws in AsyncSSH. Mitigations: We already disclosed our findings to the OpenSSH maintainers on 17th of October. Because fixing the flaw requires changes to the SSH specification, we worked together with them to come up with a specific countermeasure that ensures interoperability. We support the proposed changes in OpenSSH called "strict kex", which is negotiated as part of the SSH_MSG_KEXINIT. When negotiated, the following changes to the protocol are made: - The connection must be terminated if an unexpected or out-of-order message is received during initial key exchange. This includes insertion of any messages like SSH_MSG_IGNORE and similar, or if the SSH_MSG_KEXINIT is not the first message after the banner. - The implicit sequence numbers must be reset on every SSH_MSG_NEWKEYS. The OpenSSH project was kind enough to share with us, ahead of time, a "strict kex" patch that implements these changes (can be found in [2] as well). The patch enables you to build a version of OpenSSH that implements the proposed countermeasures for evaluation and interoperability testing. The patch also includes the amendment to the PROTOCOL file containing the specification for this extension. OpenSSH will release an updated version with these countermeasures on 18th of December 2024. As with our findings, we ask that you treat this patch confidential until public disclosure. As an alternative, less invasive countermeasure, the affected cipher modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM) may be (temporarily) disabled. Some cipher modes, in particular AES-GCM, are not affected by our findings and can still be used without changes. {quote} Draft paper and OpenSSH patch available at: [https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link] {quote}Based on feedback, OpenSSH updated the PROTOCOL specification for "strict kex" to resolve some ambiguities. First and foremost, the behaviour when encountering "strict kex" identifiers during key re-exchange is now well-defined. You can find the updated PROTOCOL specification below or in the Google Drive folder that I shared with you during the initial disclosure. If you have any additional feedback regarding this, I'll make sure to pass it along to the OpenSSH team and keep all of you updated. 1.9 transport: strict key exchange extension OpenSSH supports a number of transport-layer hardening measures under a "strict KEX" feature. This feature is signalled similarly to the RFC8305 ext-info feature: by including a additional algorithm in the initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append "kex-strict-c-...@openssh.com" to its kex_algorithms and the server may append "kex-strict-s-...@openssh.com". These pseudo-algorithms are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored if they are present in subsequent SSH2_MSG_KEXINIT packets. When an endpoint that supports this extension observes this algorithm name in a peer's KEXINIT packet, it MUST make the following changes to the the protocol: a) During initial KEX, terminate the connection if any unexpected or out-of-sequence packet is received. This includes terminating the connection if the first packet received is not SSH2_MSG_KEXINIT. Unexpected packets for the purpose of strict KEX include messages that are otherwise valid at any time during the connection such as SSH2_MSG_DEBUG and SSH2_MSG_IGNORE. b) At each SSH2_MSG_NEWKEYS me
[jira] [Created] (SSHD-1337) New Attacks on SSH Channel Integrity
Lyor Goldstein created SSHD-1337: Summary: New Attacks on SSH Channel Integrity Key: SSHD-1337 URL: https://issues.apache.org/jira/browse/SSHD-1337 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein {quote} We [1] are security researchers from the Ruhr University Bochum, and have discovered new attacks on the SSH channel integrity, which we want to disclose to you. You can find the draft version of our research paper, which we submitted to the USENIX Security conference, in [2]. Please treat it confidential until public disclosure, which is currently planned for 18th of December 2023 (2023-12-18). Prefix truncation attack on BPP: By manipulating sequence numbers during the handshake, an attacker can remove the initial messages on the secure channel, without causing a MAC failure. The vulnerable cipher modes are ChaCha20-Poly1305 (chacha20-poly1...@openssh.com) and Encrypt-then-MAC (-e...@openssh.com MAC algorithms). Practical Exploits and Impact: With channel integrity broken, we also show several exploits. An extension negotiation downgrade attack undermines channel security by removing the extension info message, and works against all compliant implementations. For example, an attacker can disable the ping extension and thus disable the new countermeasure in OpenSSH 9.5 against keystroke timing attacks. Two other exploits against AsyncSSH are even more severe, but additionally rely on implementation flaws in AsyncSSH. Mitigations: We already disclosed our findings to the OpenSSH maintainers on 17th of October. Because fixing the flaw requires changes to the SSH specification, we worked together with them to come up with a specific countermeasure that ensures interoperability. We support the proposed changes in OpenSSH called "strict kex", which is negotiated as part of the SSH_MSG_KEXINIT. When negotiated, the following changes to the protocol are made: - The connection must be terminated if an unexpected or out-of-order message is received during initial key exchange. This includes insertion of any messages like SSH_MSG_IGNORE and similar, or if the SSH_MSG_KEXINIT is not the first message after the banner. - The implicit sequence numbers must be reset on every SSH_MSG_NEWKEYS. The OpenSSH project was kind enough to share with us, ahead of time, a "strict kex" patch that implements these changes (can be found in [2] as well). The patch enables you to build a version of OpenSSH that implements the proposed countermeasures for evaluation and interoperability testing. The patch also includes the amendment to the PROTOCOL file containing the specification for this extension. OpenSSH will release an updated version with these countermeasures on 18th of December 2024. As with our findings, we ask that you treat this patch confidential until public disclosure. As an alternative, less invasive countermeasure, the affected cipher modes chacha20-poly1305 and any encrypt-then-mac variants (generic EtM) may be (temporarily) disabled. Some cipher modes, in particular AES-GCM, are not affected by our findings and can still be used without changes. {quote} Draft paper and OpenSSH patch available at: https://drive.google.com/drive/folders/1vJQYPqlaiDghv3jQ_TqOqgIowU_KO9ae?usp=drive_link {quote} Based on feedback, OpenSSH updated the PROTOCOL specification for "strict kex" to resolve some ambiguities. First and foremost, the behaviour when encountering "strict kex" identifiers during key re-exchange is now well-defined. You can find the updated PROTOCOL specification below or in the Google Drive folder that I shared with you during the initial disclosure. If you have any additional feedback regarding this, I'll make sure to pass it along to the OpenSSH team and keep all of you updated. 1.9 transport: strict key exchange extension OpenSSH supports a number of transport-layer hardening measures under a "strict KEX" feature. This feature is signalled similarly to the RFC8305 ext-info feature: by including a additional algorithm in the initiial SSH2_MSG_KEXINIT kex_algorithms field. The client may append "kex-strict-c-...@openssh.com" to its kex_algorithms and the server may append "kex-strict-s-...@openssh.com" . These pseudo-algorithms are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored if they are present in subsequent SSH2_MSG_KEXINIT packets. When an endpoint that supports this extension observes this algorithm name in a peer's KEXINIT packet, it MUST make the following changes to the the protocol: a) During initial KEX, terminate the connection if any unexpected or out-of-sequence packet is received. This includes terminating the connection if the first packet received is not SSH2_MSG_KEXINIT. Unexpected packets for the purpose of strict KEX include messages that
[jira] [Created] (SSHD-1336) Add support for SSH2_MSG_PING/PONG
Lyor Goldstein created SSHD-1336: Summary: Add support for SSH2_MSG_PING/PONG Key: SSHD-1336 URL: https://issues.apache.org/jira/browse/SSHD-1336 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein See https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL -- 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-1330) keep-alive handler on client
[ https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1330. -- Fix Version/s: 2.10.1 Resolution: Fixed > keep-alive handler on client > > > Key: SSHD-1330 > URL: https://issues.apache.org/jira/browse/SSHD-1330 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.10.0 >Reporter: Florian Hof > Assignee: Lyor Goldstein >Priority: Minor > Fix For: 2.10.1 > > > After a connection using the default SFTP client, I get lot's of WARN logs > like the following: > {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]]) > unknown global request: keepal...@proftpd.org}} > It seems that the server send keep-alive messages to the client. The > {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}} > handles this properly. It is per default in the server handlers. I propose > to add it per default in the client handlers. This shouldn't have negative > effect, should it? Adding it afterwards avoids the WARN logs. > Implementation on > {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}} > would be trivial: > {code:java} > public static final List> > DEFAULT_GLOBAL_REQUEST_HANDLERS > = List.of(OpenSshHostKeysHandler.INSTANCE, > KeepAliveHandler.INSTANCE); > {code} > (and eventually move the {{KeepAliveHandler}} from > {{org.apache.sshd.*server*.global}} to > {{{}org.apache.sshd.*common*.global{}}}). -- 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] [Closed] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1333. > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1333. -- Resolution: Won't Fix > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1333: Assignee: Lyor Goldstein > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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] [Comment Edited] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766857#comment-17766857 ] Lyor Goldstein edited comment on SSHD-1333 at 9/19/23 3:45 PM: --- I understand that - my question was what would be the +semantics+ of the extra supported options. Please note that any other option makes no sense. Please note that we can only support what SCP protocol allows - adding a bunch of options that have no meaning only muddle the API. If you need to call {{FileSystemProvider#copy(Path, Path, CopyOption...)}} then do so after translating the SCP options to {{CopyOption}}-s - if such translation is even possible {code:java|title=StandardCopyOption(s)} package java.nio.file; /** * Defines the standard copy options. * * @since 1.7 */ public enum StandardCopyOption implements CopyOption { /** * Replace an existing file if it exists. */ REPLACE_EXISTING, /** * Copy attributes to the new file. */ COPY_ATTRIBUTES, /** * Move the file as an atomic file system operation. */ ATOMIC_MOVE; } {code} {code:java|title=SCP options} public interface ScpClient extends SessionHolder, ClientSessionHolder { enum Option { Recursive("-r"), PreserveAttributes("-p"), TargetIsDirectory("-d"), ; private final String optionValue; Option(String optionValue) { this.optionValue = optionValue; } /** * @return The option value to use in the issued SCP command */ public String getOptionValue() { return optionValue; } } {code} was (Author: lgoldstein): I understand that - my question was what would be the +semantics+ of the extra supported options. Please note that any other option makes no sense. > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766857#comment-17766857 ] Lyor Goldstein commented on SSHD-1333: -- I understand that - my question was what would be the +semantics+ of the extra supported options. Please note that any other option makes no sense. > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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-1330) keep-alive handler on client
[ https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1330: - Affects Version/s: 2.10.0 > keep-alive handler on client > > > Key: SSHD-1330 > URL: https://issues.apache.org/jira/browse/SSHD-1330 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.10.0 >Reporter: Florian Hof > Assignee: Lyor Goldstein >Priority: Minor > > After a connection using the default SFTP client, I get lot's of WARN logs > like the following: > {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]]) > unknown global request: keepal...@proftpd.org}} > It seems that the server send keep-alive messages to the client. The > {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}} > handles this properly. It is per default in the server handlers. I propose > to add it per default in the client handlers. This shouldn't have negative > effect, should it? Adding it afterwards avoids the WARN logs. > Implementation on > {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}} > would be trivial: > {code:java} > public static final List> > DEFAULT_GLOBAL_REQUEST_HANDLERS > = List.of(OpenSshHostKeysHandler.INSTANCE, > KeepAliveHandler.INSTANCE); > {code} > (and eventually move the {{KeepAliveHandler}} from > {{org.apache.sshd.*server*.global}} to > {{{}org.apache.sshd.*common*.global{}}}). -- 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] [Work started] (SSHD-1330) keep-alive handler on client
[ https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1330 started by Lyor Goldstein. > keep-alive handler on client > > > Key: SSHD-1330 > URL: https://issues.apache.org/jira/browse/SSHD-1330 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Florian Hof > Assignee: Lyor Goldstein >Priority: Minor > > After a connection using the default SFTP client, I get lot's of WARN logs > like the following: > {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]]) > unknown global request: keepal...@proftpd.org}} > It seems that the server send keep-alive messages to the client. The > {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}} > handles this properly. It is per default in the server handlers. I propose > to add it per default in the client handlers. This shouldn't have negative > effect, should it? Adding it afterwards avoids the WARN logs. > Implementation on > {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}} > would be trivial: > {code:java} > public static final List> > DEFAULT_GLOBAL_REQUEST_HANDLERS > = List.of(OpenSshHostKeysHandler.INSTANCE, > KeepAliveHandler.INSTANCE); > {code} > (and eventually move the {{KeepAliveHandler}} from > {{org.apache.sshd.*server*.global}} to > {{{}org.apache.sshd.*common*.global{}}}). -- 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-1330) keep-alive handler on client
[ https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766453#comment-17766453 ] Lyor Goldstein commented on SSHD-1330: -- This is the 1st time we encounter servers sending {{keepalive}} global requests to clients. However, I see no reason why not to implement your suggestion. > keep-alive handler on client > > > Key: SSHD-1330 > URL: https://issues.apache.org/jira/browse/SSHD-1330 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Florian Hof >Priority: Minor > > After a connection using the default SFTP client, I get lot's of WARN logs > like the following: > {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]]) > unknown global request: keepal...@proftpd.org}} > It seems that the server send keep-alive messages to the client. The > {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}} > handles this properly. It is per default in the server handlers. I propose > to add it per default in the client handlers. This shouldn't have negative > effect, should it? Adding it afterwards avoids the WARN logs. > Implementation on > {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}} > would be trivial: > {code:java} > public static final List> > DEFAULT_GLOBAL_REQUEST_HANDLERS > = List.of(OpenSshHostKeysHandler.INSTANCE, > KeepAliveHandler.INSTANCE); > {code} > (and eventually move the {{KeepAliveHandler}} from > {{org.apache.sshd.*server*.global}} to > {{{}org.apache.sshd.*common*.global{}}}). -- 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-1330) keep-alive handler on client
[ https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1330: Assignee: Lyor Goldstein > keep-alive handler on client > > > Key: SSHD-1330 > URL: https://issues.apache.org/jira/browse/SSHD-1330 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Florian Hof > Assignee: Lyor Goldstein >Priority: Minor > > After a connection using the default SFTP client, I get lot's of WARN logs > like the following: > {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]]) > unknown global request: keepal...@proftpd.org}} > It seems that the server send keep-alive messages to the client. The > {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}} > handles this properly. It is per default in the server handlers. I propose > to add it per default in the client handlers. This shouldn't have negative > effect, should it? Adding it afterwards avoids the WARN logs. > Implementation on > {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}} > would be trivial: > {code:java} > public static final List> > DEFAULT_GLOBAL_REQUEST_HANDLERS > = List.of(OpenSshHostKeysHandler.INSTANCE, > KeepAliveHandler.INSTANCE); > {code} > (and eventually move the {{KeepAliveHandler}} from > {{org.apache.sshd.*server*.global}} to > {{{}org.apache.sshd.*common*.global{}}}). -- 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-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[ https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766451#comment-17766451 ] Lyor Goldstein commented on SSHD-1333: -- I don't see the use-case for this - what extra options would make sense ? > Adding java.nio.file.CopyOption to SCP transfer methods > --- > > Key: SSHD-1333 > URL: https://issues.apache.org/jira/browse/SSHD-1333 > Project: MINA SSHD > Issue Type: New Feature >Reporter: dgü >Priority: Major > > Hello! > remote-to-remote file transfer is available in SCP protocol. If I'm not > wrong, it is not available in SFTP protocol. > I'm trying to use the following code to handle remote-to-remote file transfer. > {code:java} > public class SSHDFileSystemProvider extends SftpFileSystemProvider { > private final static String URI_SCHEME = "ssh"; > > private final static boolean PRESERVE_ATTRIBUTES = true; > @Override > public String getScheme() { > return URI_SCHEME; > } > @Override > public void copy(Path sourcePath, Path targetPath, CopyOption... options) > throws IOException { > ClientSession sourceClientSession = ((SftpFileSystem) > (sourcePath.getFileSystem())).getClientSession(); > ClientSession targetClientSession = ((SftpFileSystem) > (targetPath.getFileSystem())).getClientSession(); > ScpRemote2RemoteTransferHelper helper = new > ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession); > helper.transferFile(sourcePath.toString(), targetPath.toString(), > PRESERVE_ATTRIBUTES); > } > } > {code} > _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts > preserve attributes only as the copy option. > My request: > - is it possible to add java.nio.file.CopyOption to SCP transfer methods? > Thanks in advance? -- 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-1320) how to suppress "Can't ls "some file" not found and just show error message
[ https://issues.apache.org/jira/browse/SSHD-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1320. -- Resolution: Information Provided > how to suppress "Can't ls "some file" not found and just show error message > > > Key: SSHD-1320 > URL: https://issues.apache.org/jira/browse/SSHD-1320 > Project: MINA SSHD > Issue Type: Question >Reporter: Sreedhar J >Priority: Major > > Using the Apache SFTP Server, we are able to send custom error message by > writing it to IoAsync Error streams. Error messages are shown at the client > side, but one extra message is shown at the client as below for the "ls " > command > sftp> ls hide.txt > invalid ls command, can not list hidden file > Can't ls: "/hide.txt" not found > In the above at the sftp command prompt, when we give ls hide.txt, Server > is sending the desired error message as "invalid ls command , can not list > hiddent files". but along with this error message one more extra message was > seen "*Can't ls: "/hide.txt" not found*" . So how to get rid of this "Can't > ls..." message, just to have error message. What needs to be customized on > the Apache SFTP Server side? -- 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-1320) how to suppress "Can't ls "some file" not found and just show error message
[ https://issues.apache.org/jira/browse/SSHD-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694120#comment-17694120 ] Lyor Goldstein commented on SSHD-1320: -- First of all, I would strongly advise +against+ custom error messages. It is a non-standard bottomless pit fraught with nothing but heartache. If, however, you insist on walking this path, please read [Internal exceptions and error message handling|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#internal-exceptions-and-error-message-handling] and [Intercepting data sent via STDERR channel data from the client|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#intercepting-data-sent-via-stderr-channel-data-from-the-client] and [Sending custom data via STDERR channel data to the client|https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#sending-custom-data-via-stderr-channel-data-to-the-client] > how to suppress "Can't ls "some file" not found and just show error message > > > Key: SSHD-1320 > URL: https://issues.apache.org/jira/browse/SSHD-1320 > Project: MINA SSHD > Issue Type: Question >Reporter: Sreedhar J >Priority: Major > > Using the Apache SFTP Server, we are able to send custom error message by > writing it to IoAsync Error streams. Error messages are shown at the client > side, but one extra message is shown at the client as below for the "ls " > command > sftp> ls hide.txt > invalid ls command, can not list hidden file > Can't ls: "/hide.txt" not found > In the above at the sftp command prompt, when we give ls hide.txt, Server > is sending the desired error message as "invalid ls command , can not list > hiddent files". but along with this error message one more extra message was > seen "*Can't ls: "/hide.txt" not found*" . So how to get rid of this "Can't > ls..." message, just to have error message. What needs to be customized on > the Apache SFTP Server side? -- 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-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[ https://issues.apache.org/jira/browse/SSHD-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1314: Assignee: Thomas Wolf > OpenSSHKeyPairProvider is not able to load SimpleKey > > > Key: SSHD-1314 > URL: https://issues.apache.org/jira/browse/SSHD-1314 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Jean-Baptiste Onofré >Assignee: Thomas Wolf >Priority: Major > > Since this commit: > {code:java} > commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5 > Author: Thomas Wolf > Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys > > Store host keys in the OpenSSH format. This makes it possible to use > EdDSA host keys. Also set file permissions and read legacy files more > carefully. .../AbstractGeneratorHostKeyProvider.java | 88 > ++--- > .../SimpleGeneratorHostKeyProvider.java | 109 > ++--- > .../SimpleGeneratorHostKeyProviderTest.java | 26 - > 3 files changed, 194 insertions(+), 29 deletions(-) > {code} > it's not possible to "convert" a simple key to SSH key. > > Basically, the following code worked with sshd 2.9.1: > {code:java} > File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(), > ".priv"); > privateKeyTemp.deleteOnExit(); > File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(), > ".pub"); > publicKeyTemp.deleteOnExit(); > SimpleGeneratorHostKeyProvider simpleGenerator = new > SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath()); > simpleGenerator.setKeySize(2048); > simpleGenerator.setAlgorithm("DSA"); > List keys = simpleGenerator.loadKeys(null); > KeyPair simpleKeyPair = keys.stream().findFirst().get(); > Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm()); > OpenSSHKeyPairProvider provider = > new OpenSSHKeyPairProvider(privateKeyTemp.toPath(), > publicKeyTemp.toPath(), "DSA", 2048, null); > KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next(); > Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm()); > Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded()); > Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded()); > //also test that the original file has been replaced > KeyPair keyPair = > KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath())); > Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded()); > {code} > but it fails now with sshd 2.9.2 with: > {code:java} > INFO: generateKeyPair(DSA) generating host key - size=2048 > Nov 30, 2022 6:12:35 PM > org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys > WARNING: Failed to parse keypair in > /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv. > Attempting to parse it 'directly' > Nov 30, 2022 6:12:35 PM > org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys > WARNING: Failed to parse keypair in > /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv. > Attempting to parse it as a legacy 'simple' key > Nov 30, 2022 6:12:35 PM > org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys > WARNING: > /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv > is not a 'simple' key either > {code} > because we go on the last try in the {{loadkeys()}} method. > I will work on a fix. -- 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] [Closed] (SSHD-1312) using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes
[ https://issues.apache.org/jira/browse/SSHD-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1312. Resolution: Information Provided > using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes > -- > > Key: SSHD-1312 > URL: https://issues.apache.org/jira/browse/SSHD-1312 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 >Reporter: p2 >Priority: Major > > Hi Team, > I'm using this api: > org.apache.sshd.sftp.client.SftpClient#read(org.apache.sshd.sftp.client.SftpClient.Handle, > long, byte[]) > my code is : > byte[] buff = new byte[65536]; > readLen = sftp.read(handle, 0, buff)) > my file length is bigger than 65536, > but the readLen result is 64512, > I want to know what would affect the read length. -- 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] [Closed] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[ https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1310. Resolution: Not A Problem > SftpFileSystem.close() method, closes the session as well. > --- > > Key: SSHD-1310 > URL: https://issues.apache.org/jira/browse/SSHD-1310 > Project: MINA SSHD > Issue Type: Bug >Reporter: Tilden >Priority: Major > > SftpFileSystem.close() method, closes the session as well. > We expect only the sftpfilesystem channel to be closed. Since we use the > same session for multiple operations (exec command, SFTP download & upload, > SFTP client list directory). > > SftpFileSystem.java > public void close() throws IOException { > if (this.isOpen()) { > SftpFileSystemProvider provider = this.provider(); > String fsId = this.getId(); > SftpFileSystem fs = provider.removeFileSystem(fsId); > ClientSession session = this.getClientSession(); > *session.close(true);* > if (fs != null && fs != this) { > throw new FileSystemException(fsId, fsId, "Mismatched FS > instance for id=" + fsId); > } > } > } > > > can you please check and let us know, if this can be fixed ? -- 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-1313) Seen many SFTP threads are in park state
[ https://issues.apache.org/jira/browse/SSHD-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631744#comment-17631744 ] Lyor Goldstein commented on SSHD-1313: -- {quote} So do I need to upgrade to the latest 2.9.1 library to get it sorted? {quote} Can't really say - it is very difficult to tell why you are seeing this. It may be a bug in SSHD (though I doubt it), or it may be that somehow your code does not release the threads somehow, or maybe the SFTP clients never close the connection correctly. All I can say is you have nothing to lose if you try 2.9.1 (BTW, if you wait 1-2 weeks we might have 2.9.2 out...) > Seen many SFTP threads are in park state > - > > Key: SSHD-1313 > URL: https://issues.apache.org/jira/browse/SSHD-1313 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.7.0 >Reporter: Sandeep >Priority: Major > Attachments: image-2022-11-10-13-58-06-796.png > > > Hi Team, > We have seen that SFTP threads are present in park state, Can i know any > suspected thing that I may did wrong : > !image-2022-11-10-13-58-06-796.png|width=1271,height=564! -- 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] [Closed] (SSHD-1309) SSH Jumphost with User and password Auth
[ https://issues.apache.org/jira/browse/SSHD-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1309. Resolution: Information Provided > SSH Jumphost with User and password Auth > > > Key: SSHD-1309 > URL: https://issues.apache.org/jira/browse/SSHD-1309 > Project: MINA SSHD > Issue Type: Question >Reporter: Tilden >Priority: Major > > Can you please provide documentation/example how to use SSH SSH Jumphost with > User and password Auth? > -- 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-1309) SSH Jumphost with User and password Auth
[ https://issues.apache.org/jira/browse/SSHD-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626278#comment-17626278 ] Lyor Goldstein commented on SSHD-1309: -- https://github.com/apache/mina-sshd/blob/master/docs/internals.md#ssh-jumps > SSH Jumphost with User and password Auth > > > Key: SSHD-1309 > URL: https://issues.apache.org/jira/browse/SSHD-1309 > Project: MINA SSHD > Issue Type: Question >Reporter: Tilden >Priority: Major > > Can you please provide documentation/example how to use SSH SSH Jumphost with > User and password Auth? > -- 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-1308) No exception is thrown if setting environment variable is ignored by SSH server
[ https://issues.apache.org/jira/browse/SSHD-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623295#comment-17623295 ] Lyor Goldstein commented on SSHD-1308: -- To add to it {quote} ignored by SSH server and exit code returns 0 {quote} How can the client tell that the server ignored the variable ? Like [~twolf] said: {quote} You could implement this yourself, but it'd be quite involved. {quote} Which means it would be a +custom+ implementation that will work only with your client and server. > No exception is thrown if setting environment variable is ignored by SSH > server > --- > > Key: SSHD-1308 > URL: https://issues.apache.org/jira/browse/SSHD-1308 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.9.1 > Environment: Java 8 >Reporter: dgü >Priority: Major > > Hello! > If an environment variable set by > _org.apache.sshd.client.session.ClientSession#createExecChannel(command,null,env)_ > is ignored by SSH server and exit code returns 0, then this may cause > unexpected behaviour in client application. > For example, client application may do different tasks when an environment > variable is set and not set. In both cases, client application may return 0. > Client application may assume that it worked successfully. But, indeed its > environment variable is ignored and worked as if environment variable is not > set. > is it possible throw an exception if setting environment variable is ignored > by SSH server ? > Thanks in advance... > > -- 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] [Closed] (SSHD-1308) No exception is thrown if setting environment variable is ignored by SSH server
[ https://issues.apache.org/jira/browse/SSHD-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1308. Resolution: Information Provided > No exception is thrown if setting environment variable is ignored by SSH > server > --- > > Key: SSHD-1308 > URL: https://issues.apache.org/jira/browse/SSHD-1308 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.9.1 > Environment: Java 8 >Reporter: dgü >Priority: Major > > Hello! > If an environment variable set by > _org.apache.sshd.client.session.ClientSession#createExecChannel(command,null,env)_ > is ignored by SSH server and exit code returns 0, then this may cause > unexpected behaviour in client application. > For example, client application may do different tasks when an environment > variable is set and not set. In both cases, client application may return 0. > Client application may assume that it worked successfully. But, indeed its > environment variable is ignored and worked as if environment variable is not > set. > is it possible throw an exception if setting environment variable is ignored > by SSH server ? > Thanks in advance... > > -- 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] [Closed] (SSHD-1306) SFTP threads are showing in parked state
[ https://issues.apache.org/jira/browse/SSHD-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1306. Resolution: Incomplete > SFTP threads are showing in parked state > > > Key: SSHD-1306 > URL: https://issues.apache.org/jira/browse/SSHD-1306 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.5.1 >Reporter: Sandeep >Priority: Major > Attachments: image-2022-10-19-20-18-07-483.png > > > Hi Team, > We have seen many sftp threads in a parking state and it pointing to a queue > (LinkedBlockingQueue) from SftpSubsystem. > *Use case:* We are sending many files per session. > Current Apache SFTP lib version: 2.5.1 > Can you please guide/feedback/suggestions for us to solve this problem? > !image-2022-10-19-20-18-07-483.png|width=1198,height=540! -- 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-1306) SFTP threads are showing in parked state
[ https://issues.apache.org/jira/browse/SSHD-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17621412#comment-17621412 ] Lyor Goldstein commented on SSHD-1306: -- Version 2.5.1 is extremely old - there were +many+ (many, many, many,...) improvements and bug fixes. Please try the latest version (2.9.1). That being said, it is extremely hard to say anything useful without +lots+ of more information about what you are doing, how you are doing it, what frequency, etc.. BTW, it can certainly be argued that perhaps you have a bug that does not release sessions correctly or quickly enough and thus are keeping them alive somehow. {quote} once we have new session ideally it should reuse the parked thread {quote} Can you provide some idea as to how this can be done in Java ? I am not aware of +any+ such API. > SFTP threads are showing in parked state > > > Key: SSHD-1306 > URL: https://issues.apache.org/jira/browse/SSHD-1306 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.5.1 >Reporter: Sandeep >Priority: Major > Attachments: image-2022-10-19-20-18-07-483.png > > > Hi Team, > We have seen many sftp threads in a parking state and it pointing to a queue > (LinkedBlockingQueue) from SftpSubsystem. > *Use case:* We are sending many files per session. > Current Apache SFTP lib version: 2.5.1 > Can you please guide/feedback/suggestions for us to solve this problem? > !image-2022-10-19-20-18-07-483.png|width=1198,height=540! -- 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] [Comment Edited] (SSHD-1304) SFTP Asynchronous API
[ https://issues.apache.org/jira/browse/SSHD-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17621410#comment-17621410 ] Lyor Goldstein edited comment on SSHD-1304 at 10/20/22 11:50 PM: - I am not sure how such an API would work - at least not in any simple way. In any case, such an API involves a +lot+ of time for designing, developing and testing, but does not seem to have any current real-life demand (you are the 1st who ever requested it). In view of this, I do not think we can afford to invest the +extremely+ few R&D resources we have on it. I am not closing this request so that it can be viewed by others and maybe gain enough support to warrant our involvement or maybe we will get to it if we somehow obtain more R&D resources, You are more than welcome to develop such an API and publish a PR for it - we more than welcome contributions from our users. was (Author: lgoldstein): I am not sure how such an API would work - at least not in any simple way. In any case, since such an API involves a +lot+ of time for designing, developing and testing, but does not seem to have any current real-life demand (you are the 1st who ever requested it). In view of this, I do not think we can afford to invest the +extremely+ few R&D resources we have on it. I am not closing this request so that it can be viewed by others and maybe gain enough support to warrant our involvement or maybe we will get to it if we somehow obtain more R&D resources, You are more than welcome to develop such an API and publish a PR for it - we more than welcome contributions from our users. > SFTP Asynchronous API > - > > Key: SSHD-1304 > URL: https://issues.apache.org/jira/browse/SSHD-1304 > Project: MINA SSHD > Issue Type: Wish >Affects Versions: 2.8.0 >Reporter: Baptiste AIGLIN >Priority: Minor > > Hi, > I have been trying Apache Mina as SFTP client in order to replace the current > library we are using to perform Sftp client calls. > I understand that Apache MINA is using nio internally for performance > reasons, however maybe it is a stupid question, but I was wondering why there > is no Asynchronous methods (No future for instance for return type) on the > SftpClient itslef. > > Many thanks for reply. -- 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-1304) SFTP Asynchronous API
[ https://issues.apache.org/jira/browse/SSHD-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1304: - Issue Type: Wish (was: Question) > SFTP Asynchronous API > - > > Key: SSHD-1304 > URL: https://issues.apache.org/jira/browse/SSHD-1304 > Project: MINA SSHD > Issue Type: Wish >Affects Versions: 2.8.0 >Reporter: Baptiste AIGLIN >Priority: Minor > > Hi, > I have been trying Apache Mina as SFTP client in order to replace the current > library we are using to perform Sftp client calls. > I understand that Apache MINA is using nio internally for performance > reasons, however maybe it is a stupid question, but I was wondering why there > is no Asynchronous methods (No future for instance for return type) on the > SftpClient itslef. > > Many thanks for reply. -- 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-1304) SFTP Asynchronous API
[ https://issues.apache.org/jira/browse/SSHD-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17621410#comment-17621410 ] Lyor Goldstein commented on SSHD-1304: -- I am not sure how such an API would work - at least not in any simple way. In any case, since such an API involves a +lot+ of time for designing, developing and testing, but does not seem to have any current real-life demand (you are the 1st who ever requested it). In view of this, I do not think we can afford to invest the +extremely+ few R&D resources we have on it. I am not closing this request so that it can be viewed by others and maybe gain enough support to warrant our involvement or maybe we will get to it if we somehow obtain more R&D resources, You are more than welcome to develop such an API and publish a PR for it - we more than welcome contributions from our users. > SFTP Asynchronous API > - > > Key: SSHD-1304 > URL: https://issues.apache.org/jira/browse/SSHD-1304 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 >Reporter: Baptiste AIGLIN >Priority: Minor > > Hi, > I have been trying Apache Mina as SFTP client in order to replace the current > library we are using to perform Sftp client calls. > I understand that Apache MINA is using nio internally for performance > reasons, however maybe it is a stupid question, but I was wondering why there > is no Asynchronous methods (No future for instance for return type) on the > SftpClient itslef. > > Many thanks for reply. -- 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-1305) ProcessBuilder redirection equivalents for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1305: Assignee: Lyor Goldstein > ProcessBuilder redirection equivalents for ChannelExec > -- > > Key: SSHD-1305 > URL: https://issues.apache.org/jira/browse/SSHD-1305 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java 8 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > are there any equivalents of _ProcessBuilder#redirectError(...)_, > _ProcessBuilder#redirectInput(...)_ and _ProcessBuilder#redirectOutput(...)_ > for _org.apache.sshd.client.channel.ChannelExec_ ? > Thanks in advance... -- 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] [Closed] (SSHD-1305) ProcessBuilder redirection equivalents for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1305. Resolution: Information Provided > ProcessBuilder redirection equivalents for ChannelExec > -- > > Key: SSHD-1305 > URL: https://issues.apache.org/jira/browse/SSHD-1305 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java 8 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > are there any equivalents of _ProcessBuilder#redirectError(...)_, > _ProcessBuilder#redirectInput(...)_ and _ProcessBuilder#redirectOutput(...)_ > for _org.apache.sshd.client.channel.ChannelExec_ ? > Thanks in advance... -- 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-1305) ProcessBuilder redirection equivalents for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619670#comment-17619670 ] Lyor Goldstein commented on SSHD-1305: -- {quote} I tried ChannelExec#setRedirectErrorStream(boolean) and ChannelExec#isRedirectErrorStream() {quote} This is all there is since there is no default implementation for redirecting STDIN/STDOUT - +you+ are supposed to provide the relevant streams anyway when you set up {{ChannelExec}}. The only reasonable redirection is to use STDOUT as STDERR stream as well. > ProcessBuilder redirection equivalents for ChannelExec > -- > > Key: SSHD-1305 > URL: https://issues.apache.org/jira/browse/SSHD-1305 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java 8 >Reporter: dgü >Priority: Major > > Hello! > are there any equivalents of _ProcessBuilder#redirectError(...)_, > _ProcessBuilder#redirectInput(...)_ and _ProcessBuilder#redirectOutput(...)_ > for _org.apache.sshd.client.channel.ChannelExec_ ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617098#comment-17617098 ] Lyor Goldstein commented on SSHD-1300: -- {quote} it is not possible to get environment variables without executing a separate remote command such as env on UNIX. {quote} It is also my understanding > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616537#comment-17616537 ] Lyor Goldstein commented on SSHD-1300: -- {quote} I mean if it is possible to get environment variables before executing remote command without executing separate additional command such as env on UNIX ? {quote} To (re-)quote myself {quote} If you want to know what the peer environment is, then AFAIK there is no standard SSH way to do it. {quote} > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616536#comment-17616536 ] Lyor Goldstein commented on SSHD-1300: -- {quote} org.apache.sshd.client.session.ClientSession#createExecChannel(...) can be a step of equivalent of java.lang.ProcessBuilder#start(). {quote} Disagree - the API does not provide environment variables. Not sure what you mean by {quote} is there an equivalent of java.lang.ProcessBuilder#environment() ? {quote} From the [javadoc|https://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html#environment()] IMO the API I referred to provides the same functionality. +You+ decide what the environment is via the parameters +you+ provide. If you want to know what the +peer+ environment is, then AFAIK there is no standard SSH way to do it. > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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] [Comment Edited] (SSHD-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616507#comment-17616507 ] Lyor Goldstein edited comment on SSHD-1300 at 10/12/22 3:17 PM: {code:java|title=ClientSession} /** * Create a channel to execute a command using specific PTY settings and/or environment. * * @param command The command to execute * @param ptyConfig The PTY configuration to use - if {@code null} then internal defaults are used * @param env Extra environment configuration to be transmitted to the server - ignored if * {@code null}/empty. * @return The created {@link ChannelExec} * @throws IOException If failed to create the requested channel */ ChannelExec createExecChannel( String command, PtyChannelConfigurationHolder ptyConfig, Map env) throws IOException; {code} was (Author: lgoldstein): {code:java|title=ClientSession} /** * Create a channel to execute a command using specific PTY settings and/or environment. * * @param command The command to execute * @param ptyConfig The PTY configuration to use - if {@code null} then internal defaults are used * @param env Extra environment configuration to be transmitted to the server - ignored if * {@code null}/empty. * @return The created {@link ChannelExec} * @throws IOException If failed to create the requested channel */ ChannelExec createExecChannel( String command, PtyChannelConfigurationHolder ptyConfig, Map env) throws IOException; {code} > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616507#comment-17616507 ] Lyor Goldstein commented on SSHD-1300: -- {code:java|title=ClientSession} /** * Create a channel to execute a command using specific PTY settings and/or environment. * * @param command The command to execute * @param ptyConfig The PTY configuration to use - if {@code null} then internal defaults are used * @param env Extra environment configuration to be transmitted to the server - ignored if * {@code null}/empty. * @return The created {@link ChannelExec} * @throws IOException If failed to create the requested channel */ ChannelExec createExecChannel( String command, PtyChannelConfigurationHolder ptyConfig, Map env) throws IOException; {code} > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1300. -- Resolution: Information Provided > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1300) ProcessBuilder#environment() equivalent for ChannelExec
[ https://issues.apache.org/jira/browse/SSHD-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1300: Assignee: Lyor Goldstein > ProcessBuilder#environment() equivalent for ChannelExec > --- > > Key: SSHD-1300 > URL: https://issues.apache.org/jira/browse/SSHD-1300 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.9.1 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > is there an equivalent of _java.lang.ProcessBuilder#environment()_ for > _org.apache.sshd.client.channel.ChannelExec_ ? > If not, is there a workround to get environment variables of _ChannelExec_ > before executing remote command ? > Thanks in advance... -- 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-1299) CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT name is misleading
[ https://issues.apache.org/jira/browse/SSHD-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1299: - Priority: Minor (was: Major) > CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT name is misleading > -- > > Key: SSHD-1299 > URL: https://issues.apache.org/jira/browse/SSHD-1299 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Gili >Priority: Minor > > CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT is documented as "Minimum NIO2 > write wait timeout for a single outgoing packet - in milliseconds" but if you > look at the implementation of Nio2Session.doWriteCycle, it is used as the > second parameter of socket.write(). This parameter (timeout) is documented as > "The maximum time for the I/O operation to complete" > Hence, I would expect the parameter name to contain MAX not MIN, and the > Javadoc should explain this value corresponds to the *maximum* amount of time > to wait for a write to complete. -- 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-1299) CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT name is misleading
[ https://issues.apache.org/jira/browse/SSHD-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1299: - Issue Type: Improvement (was: Bug) > CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT name is misleading > -- > > Key: SSHD-1299 > URL: https://issues.apache.org/jira/browse/SSHD-1299 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Gili >Priority: Major > > CoreModuleProperties.NIO2_MIN_WRITE_TIMEOUT is documented as "Minimum NIO2 > write wait timeout for a single outgoing packet - in milliseconds" but if you > look at the implementation of Nio2Session.doWriteCycle, it is used as the > second parameter of socket.write(). This parameter (timeout) is documented as > "The maximum time for the I/O operation to complete" > Hence, I would expect the parameter name to contain MAX not MIN, and the > Javadoc should explain this value corresponds to the *maximum* amount of time > to wait for a write to complete. -- 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] [Closed] (SSHD-1297) Load public key from file
[ https://issues.apache.org/jira/browse/SSHD-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1297. Resolution: Information Provided > Load public key from file > - > > Key: SSHD-1297 > URL: https://issues.apache.org/jira/browse/SSHD-1297 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.1 > Environment: org.apache.sshd:sshd-sftp:2.9.1 > + > openjdk version "17.0.3" 2022-04-19 > OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7) > OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, > sharing) >Reporter: Daniel Hammer >Priority: Minor > > Hi SSHD gurus, > I'm attempting to utilize > {{org.apache.sshd.common.util.buffer.ByteArrayBuffer}} to load a > {{java.security.PublicKey}}, in-order to subsequently register the public key > in a {{{}org.apache.sshd.server.auth.pubkey.PublickeyAuthenticator{}}}. > Ie. the idea is something like this > {code:java} > PublicKey myPublicKey; > try (InputStream is = new > FileInputStream("/home/my-user/tmp/test_rsa_key.pub")) { > ByteArrayBuffer buffer = new > ByteArrayBuffer(org.apache.sshd.common.util.io.IoUtils.IoUtils.toByteArray(is)); > myPublicKey = buffer.getPublicKey(); // -> OutOfMemoryError: Java heap > space ..? > // myPublicKey = buffer.getRawPublicKey(); // -> Underflow ..? > } > ServerBuilder.builder() > .publickeyAuthenticator(new KeySetPublickeyAuthenticator("my id", > List.of(myPublicKey))) > .build(); > {code} > Resulting in the below exceptions, caused by internal guarding in > {{ByteArrayBuffer}} before the {{ByteArrayBuffer.data}} would be processed. > {{{}getPublicKey(){}}}: > {code:java} > java.lang.OutOfMemoryError: Java heap space > at > org.apache.sshd.common.util.buffer.ByteArrayBuffer.ensureCapacity(ByteArrayBuffer.java:277) > at > org.apache.sshd.common.util.buffer.Buffer.ensureCapacity(Buffer.java:1105) > at > org.apache.sshd.common.util.buffer.ByteArrayBuffer.wpos(ByteArrayBuffer.java:139) > at > org.apache.sshd.common.util.buffer.Buffer.getPublicKey(Buffer.java:521) > at > org.apache.sshd.common.util.buffer.Buffer.getPublicKey(Buffer.java:505) > {code} > {{{}getRawPublicKey(){}}}: > {code:java} > org.apache.sshd.common.util.buffer.BufferException: Underflow: > requested=1936943149, available=737 > at > org.apache.sshd.common.util.buffer.Buffer.ensureAvailable(Buffer.java:640) > at > org.apache.sshd.common.util.buffer.ByteArrayBuffer.getString(ByteArrayBuffer.java:241) > at org.apache.sshd.common.util.buffer.Buffer.getString(Buffer.java:309) > at > org.apache.sshd.common.util.buffer.Buffer.getRawPublicKey(Buffer.java:541) > at > org.apache.sshd.common.util.buffer.Buffer.getRawPublicKey(Buffer.java:530) > {code} > Seemingly my approach is incompatible with the available logic, unfortunately > I've been unable to uncover documentation or Javadoc that could aid. > So as a last resort I'm turning to you gurus, in hopes of enlightenment (+ > perhaps a PR guiding future developers in the desired direction via > documentation / Javadoc). > Thanks in advance 🙏 -- 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-1295) Connection attempt not canceled when a connection timeout occurs
[ https://issues.apache.org/jira/browse/SSHD-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603147#comment-17603147 ] Lyor Goldstein commented on SSHD-1295: -- I agree - the code seems very complex as it is. While I agree this is an issue I do not think it is a major one - there do not seem to be any real complaints about the current behavior. Let's stick with "better the devil you know" but keep this issue open - maybe in some future code re-structuring we might have a better idea as to the more correct behavior. > Connection attempt not canceled when a connection timeout occurs > > > Key: SSHD-1295 > URL: https://issues.apache.org/jira/browse/SSHD-1295 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Thomas Wolf >Priority: Major > > This is not a new bug; it's also present in earlier versions. > When {{client.connect().verify(timeout)}} times out, the underlying > asynchronous connection attempt still continues _and may still succeed_. If > that happens, there is a connection and session that the user cannot use or > close. (Short of calling verify().getSession() again, but that is a pattern I > have never seen, and it also makes using a timeout rather useless.) > This means that timeouts are inherently unreliable. > Here's a simple test case illustrating this problem (for > {{org.apache.sshd.client.ClientTest}}): > {code:java} > @Test > public void testConnectTimeout() throws Exception { > client.start(); > try { > ConnectFuture future = client.connect(getCurrentTestName(), > TEST_LOCALHOST, port); > try { > future.verify(1); > fail("Timeout expected"); > } catch (InterruptedIOException | SshException e) { > ClientSession session = null; > try { > session = future.verify(CONNECT_TIMEOUT).getSession(); > } catch (SshException e2) { > assertTrue("Expected a timeout, got " + e2, > e2.getMessage().contains("timeout")); > } > if (session != null) { > assertTrue("Session should be closed", session.isClosed() || > session.isClosing()); > } > } > } finally { > client.stop(); > } > } > {code} > This test fails. > When the {{ConnectFuture}} times out (or is canceled, or waiting is > interrupted), the underlying {{IoConnectFuture}} must be canceled. If we do > get an {{IoSession}} all the same, but the {{ConnectFuture}} is already > canceled or timed out, the {{IoSession}} must be closed immediately. > Preferrably before a {{Session}} is created at all; otherwise, that SSH > session must be closed, too. Creating a {{ClientSession}} already starts the > application-level protocol (sending the SSH ident, or if a proxy is used, the > proxy connect request). > The test also highlights another problem: there is no clear indication that > the failure of {{verify()}} indicates a timeout. Probably there should be a > dedicated exception for this, or at least the {{SshException}} should have a > {{TimeoutException}} as cause. -- 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-1295) Connection attempt not canceled when a connection timeout occurs
[ https://issues.apache.org/jira/browse/SSHD-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602888#comment-17602888 ] Lyor Goldstein commented on SSHD-1295: -- {quote} Another shortcoming of the current approach in PR 242 is that it does create the ClientSession first, which already sends messages, and only then decides to close the session again. However, avoiding that would be a much more invasive change that would have to re-define the way a ClientSession is started: basically, don't send messages in the constructor already but have a separate start() method that would have to be called after the session object was fully created. {quote} IMO it would be even more invasive change than imagined - there is code that +relies+ on the fact that some initial messages are sent immediately upon construction. Delaying this until _start()_ is called, may prove quite complex... > Connection attempt not canceled when a connection timeout occurs > > > Key: SSHD-1295 > URL: https://issues.apache.org/jira/browse/SSHD-1295 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Thomas Wolf >Priority: Major > > This is not a new bug; it's also present in earlier versions. > When {{client.connect().verify(timeout)}} times out, the underlying > asynchronous connection attempt still continues _and may still succeed_. If > that happens, there is a connection and session that the user cannot use or > close. (Short of calling verify().getSession() again, but that is a pattern I > have never seen, and it also makes using a timeout rather useless.) > This means that timeouts are inherently unreliable. > Here's a simple test case illustrating this problem (for > {{org.apache.sshd.client.ClientTest}}): > {code:java} > @Test > public void testConnectTimeout() throws Exception { > client.start(); > try { > ConnectFuture future = client.connect(getCurrentTestName(), > TEST_LOCALHOST, port); > try { > future.verify(1); > fail("Timeout expected"); > } catch (InterruptedIOException | SshException e) { > ClientSession session = null; > try { > session = future.verify(CONNECT_TIMEOUT).getSession(); > } catch (SshException e2) { > assertTrue("Expected a timeout, got " + e2, > e2.getMessage().contains("timeout")); > } > if (session != null) { > assertTrue("Session should be closed", session.isClosed() || > session.isClosing()); > } > } > } finally { > client.stop(); > } > } > {code} > This test fails. > When the {{ConnectFuture}} times out (or is canceled, or waiting is > interrupted), the underlying {{IoConnectFuture}} must be canceled. If we do > get an {{IoSession}} all the same, but the {{ConnectFuture}} is already > canceled or timed out, the {{IoSession}} must be closed immediately. > Preferrably before a {{Session}} is created at all; otherwise, that SSH > session must be closed, too. Creating a {{ClientSession}} already starts the > application-level protocol (sending the SSH ident, or if a proxy is used, the > proxy connect request). > The test also highlights another problem: there is no clear indication that > the failure of {{verify()}} indicates a timeout. Probably there should be a > dedicated exception for this, or at least the {{SshException}} should have a > {{TimeoutException}} as cause. -- 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-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[ https://issues.apache.org/jira/browse/SSHD-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598499#comment-17598499 ] Lyor Goldstein commented on SSHD-1293: -- A GitHub PR based on https://github.com/apache/mina-sshd is the best way - this way my colleagues will also be able to review and comment > ExplicitPortForwardingTracker does not unbind auto-allocated one > > > Key: SSHD-1293 > URL: https://issues.apache.org/jira/browse/SSHD-1293 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Philipp >Priority: Major > > I have noticed that the de-allocation (unbind of a forwarding) initiated by > {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in > the {{close()}} method will not no close the actual forwarding. Said that, > this leaves the connection and a file handler open. > The actual main reason is that it uses > \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it > stops the tunnel identified the "local address" which is the same as provided > by the user. If the user is using a local address with port {{0}} (which > seems legit since the docs state this explicitly), the local address will be > still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the > "bound address" contains the actual dynamic auto-allocated port. > If the user uses an explicit port, this would work. > As a workaround, I have added after {{tracker.close()}} an explicit > {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know > if this would your final solution or this would be an issue in > \{{DefaultForwarder#stopLocalPortForwarding}}. > > I'm using 2.8 right now; as far as I can see there are no changes in 2.9 > regarding this. -- 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-1293) ExplicitPortForwardingTracker does not unbind auto-allocated one
[ https://issues.apache.org/jira/browse/SSHD-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597999#comment-17597999 ] Lyor Goldstein commented on SSHD-1293: -- Your analysis seems correct, as does the fix you propose - how about creating a PR with your proposal and run all the relevant tests on it ? This would also make you a contributor to our code - something we always encourage. > ExplicitPortForwardingTracker does not unbind auto-allocated one > > > Key: SSHD-1293 > URL: https://issues.apache.org/jira/browse/SSHD-1293 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Philipp >Priority: Major > > I have noticed that the de-allocation (unbind of a forwarding) initiated by > {{org.apache.sshd.client.session.forward.ExplicitPortForwardingTracker}} in > the {{close()}} method will not no close the actual forwarding. Said that, > this leaves the connection and a file handler open. > The actual main reason is that it uses > \{{manager.stopLocalPortForwarding(this.getLocalAddress());}} which means it > stops the tunnel identified the "local address" which is the same as provided > by the user. If the user is using a local address with port {{0}} (which > seems legit since the docs state this explicitly), the local address will be > still something like {{0.0.0.0:0}} or maybe {{{}127.0.0.1:0{}}}, but only the > "bound address" contains the actual dynamic auto-allocated port. > If the user uses an explicit port, this would work. > As a workaround, I have added after {{tracker.close()}} an explicit > {{session.stopLocalPortForwarding(tracker.getBoundAddress())}}. I don't know > if this would your final solution or this would be an issue in > \{{DefaultForwarder#stopLocalPortForwarding}}. > > I'm using 2.8 right now; as far as I can see there are no changes in 2.9 > regarding this. -- 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
Re: [VOTE] Release Apache Mina SSHD 2.9.1
+1
[jira] [Commented] (SSHD-1287) Use the maximum packet size of the communication partner
[ https://issues.apache.org/jira/browse/SSHD-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17581235#comment-17581235 ] Lyor Goldstein commented on SSHD-1287: -- {quote} I wrote about packet sizes, not window sizes, {quote} I know - a slip of the tongue from my part - I also meant packet sizes (which are 32-bit so potentially 2**32-1) {quote} I didn't say anywhere anything about not having any limits {quote} No, you did not - I merely added this as a reminder - I see we are basically agreeing on this. > Use the maximum packet size of the communication partner > > > Key: SSHD-1287 > URL: https://issues.apache.org/jira/browse/SSHD-1287 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Thomas Wolf >Priority: Minor > Attachments: ClientMain.java, ConsoleLog, ServerMain.java > > > It appears that SSHD may use the maximum packet size presented by the > communicating party to request reception. > RFC 4254 contains the following statement, where "maximum packet size" can be > read as "the maximum packet size that the sender is willing to accept" (as in > "initial window size"). > {code:java} > Section 5.1 Opening a Channel > The 'maximum packet size' specifies the maximum size of > 2an individual data packet that can be sent to the sender.{code} > The client/server must comply with its own declared maximum packet size. > > I encountered this issue when I was using "freeSSHd" as an SFTP server. > The version of freeSSHd is 1.3.1. > The event is confirmed by creating a server with SSHD. > Attached are the client and server sources, as well as the client debug logs > (up to the first read request). > When communicating with these, the client knows that its maximum packet size > is "32768" and the server's maximum packet size is "65536". > {code:java} > // client window > [main] DEBUG org.apache.sshd.common.channel.Window - > init(Window[client/local](SftpChannelSubsystem[id=0, > recipient=-1]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=32768 > // server window > [sshd-SshClient[5702b3b1]-nio2-thread-3] DEBUG > org.apache.sshd.common.channel.Window - > init(Window[client/remote](SftpChannelSubsystem[id=0, > recipient=0]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=65536 {code} > And when requesting to receive a file, it requests to read 65536 bytes at a > time. This means that it attempts to receive packets that exceed 32768 bytes. > {code:java} > [main] TRACE org.apache.sshd.sftp.client.impl.SftpInputStreamAsync - > sendRequests(SftpInputStreamAsync[ClientSessionImpl[user@localhost/127.0.0.1:10022]][/data4M.txt]) > enqueue pending ack: SftpAckData[id=103, offset=0, length=65536] {code} > > I hope this report is helpful. > I am doing machine translation, so please allow it to be unnatural. -- 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] [Comment Edited] (SSHD-1287) Use the maximum packet size of the communication partner
[ https://issues.apache.org/jira/browse/SSHD-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17580907#comment-17580907 ] Lyor Goldstein edited comment on SSHD-1287 at 8/17/22 5:31 PM: --- [~twolf] while I agree in principle with your analysis, I am not sure we want to use the window sizes without some internal limit. My concern is about possibly introducing an OOM "attack" by someone intentionally or due to some misconfiguration requesting a read window size of 100's of MB or even GB's (BTW - what about a virtually unlimited window of size 2**32-1 that we support...). When the code will try to accommodate this request it may eventually run out of memory (maybe not as a single allocation but as a cumulative pending queue of packets). This is why we impose (sometimes artificial) limits whenever the input value serves as allocation size. We could use a larger (configurable) limit - e.g., 256K instead of 64K by default, and also address the behavior you described {quote} 10 read requests to read 100kB at offsets 0, 100kB, 200kB, 300kB {quote} and also {quote} If a bufferSize > 126kB (twice the server's read size limit) is used, SftpInputStreamAsync has a bug that overwrites data during this synchronous re-load of missing data, so the file is corrupted in the transfer. {quote} I believe this will achieve the desired balance between optimized throughput and protecting the code from inadvertent (or intentional) OOM. was (Author: lgoldstein): [~twolf] while I agree in principle with your analysis, I am not sure we want to use the window sizes without some internal limit. My concern is about possibly introducing an OOM "attack" by someone intentionally or due to some misconfiguration requesting a read window size of 100's of MB or even GB's (BTW - what about a virtually unlimited window of size 2**32-1 that we support...). When the code will try to accommodate this request it may eventually run out of memory (maybe not as a single allocation but as a cumulative pending queue of packets). This is why we impose (sometimes artificial) limits whenever the input value serves as allocation size. We could use a larger (configurable) limit - e.g., 256K instead of 64K by default, and also address the behavior you described {quote} 10 read requests to read 100kB at offsets 0, 100kB, 200kB, 300kB {quote} I believe this will achieve the desired balance between optimized throughput and protecting the code from inadvertent (or intentional) OOM. > Use the maximum packet size of the communication partner > > > Key: SSHD-1287 > URL: https://issues.apache.org/jira/browse/SSHD-1287 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Thomas Wolf >Priority: Minor > Attachments: ClientMain.java, ConsoleLog, ServerMain.java > > > It appears that SSHD may use the maximum packet size presented by the > communicating party to request reception. > RFC 4254 contains the following statement, where "maximum packet size" can be > read as "the maximum packet size that the sender is willing to accept" (as in > "initial window size"). > {code:java} > Section 5.1 Opening a Channel > The 'maximum packet size' specifies the maximum size of > 2an individual data packet that can be sent to the sender.{code} > The client/server must comply with its own declared maximum packet size. > > I encountered this issue when I was using "freeSSHd" as an SFTP server. > The version of freeSSHd is 1.3.1. > The event is confirmed by creating a server with SSHD. > Attached are the client and server sources, as well as the client debug logs > (up to the first read request). > When communicating with these, the client knows that its maximum packet size > is "32768" and the server's maximum packet size is "65536". > {code:java} > // client window > [main] DEBUG org.apache.sshd.common.channel.Window - > init(Window[client/local](SftpChannelSubsystem[id=0, > recipient=-1]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=32768 > // server window > [sshd-SshClient[5702b3b1]-nio2-thread-3] DEBUG > org.apache.sshd.common.channel.Window - > init(Window[client/remote](SftpChannelSubsystem[id=0, > recipient=0]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=65536 {code} > And when requesting to receive a file, it requests to read 65536 bytes at a > time. This
[jira] [Commented] (SSHD-1287) Use the maximum packet size of the communication partner
[ https://issues.apache.org/jira/browse/SSHD-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17580907#comment-17580907 ] Lyor Goldstein commented on SSHD-1287: -- [~twolf] while I agree in principle with your analysis, I am not sure we want to use the window sizes without some internal limit. My concern is about possibly introducing an OOM "attack" by someone intentionally or due to some misconfiguration requesting a read window size of 100's of MB or even GB's (BTW - what about a virtually unlimited window of size 2**32-1 that we support...). When the code will try to accommodate this request it may eventually run out of memory (maybe not as a single allocation but as a cumulative pending queue of packets). This is why we impose (sometimes artificial) limits whenever the input value serves as allocation size. We could use a larger (configurable) limit - e.g., 256K instead of 64K by default, and also address the behavior you described {quote} 10 read requests to read 100kB at offsets 0, 100kB, 200kB, 300kB {quote} I believe this will achieve the desired balance between optimized throughput and protecting the code from inadvertent (or intentional) OOM. > Use the maximum packet size of the communication partner > > > Key: SSHD-1287 > URL: https://issues.apache.org/jira/browse/SSHD-1287 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Thomas Wolf >Priority: Minor > Attachments: ClientMain.java, ConsoleLog, ServerMain.java > > > It appears that SSHD may use the maximum packet size presented by the > communicating party to request reception. > RFC 4254 contains the following statement, where "maximum packet size" can be > read as "the maximum packet size that the sender is willing to accept" (as in > "initial window size"). > {code:java} > Section 5.1 Opening a Channel > The 'maximum packet size' specifies the maximum size of > 2an individual data packet that can be sent to the sender.{code} > The client/server must comply with its own declared maximum packet size. > > I encountered this issue when I was using "freeSSHd" as an SFTP server. > The version of freeSSHd is 1.3.1. > The event is confirmed by creating a server with SSHD. > Attached are the client and server sources, as well as the client debug logs > (up to the first read request). > When communicating with these, the client knows that its maximum packet size > is "32768" and the server's maximum packet size is "65536". > {code:java} > // client window > [main] DEBUG org.apache.sshd.common.channel.Window - > init(Window[client/local](SftpChannelSubsystem[id=0, > recipient=-1]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=32768 > // server window > [sshd-SshClient[5702b3b1]-nio2-thread-3] DEBUG > org.apache.sshd.common.channel.Window - > init(Window[client/remote](SftpChannelSubsystem[id=0, > recipient=0]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp])) > size=2097152, max=2097152, packet=65536 {code} > And when requesting to receive a file, it requests to read 65536 bytes at a > time. This means that it attempts to receive packets that exceed 32768 bytes. > {code:java} > [main] TRACE org.apache.sshd.sftp.client.impl.SftpInputStreamAsync - > sendRequests(SftpInputStreamAsync[ClientSessionImpl[user@localhost/127.0.0.1:10022]][/data4M.txt]) > enqueue pending ack: SftpAckData[id=103, offset=0, length=65536] {code} > > I hope this report is helpful. > I am doing machine translation, so please allow it to be unnatural. -- 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-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574329#comment-17574329 ] Lyor Goldstein commented on SSHD-1281: -- {quote} BTW, with Jeremy's fix I think we can remove the "release" profile. {quote} I think we should not take any chance of something else going wrong and make sure we are compiling Java 8 code. > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574328#comment-17574328 ] Lyor Goldstein commented on SSHD-1281: -- [~twolf]] {quote} Can you do it, or do we need to ping Guillaume? {quote} Sorry, I cannot (for various reasons) - we need to involve [~gnodet] > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(Abst
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573861#comment-17573861 ] Lyor Goldstein commented on SSHD-1281: -- {quote} As for the root cause: most likely SSHD-1285. It looks like the 2.9.0 release was built incorrectly (missing --release 8 when compiling) {quote} [~twolf] can we release 2.9.1 correctly compiled ? > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.com
[jira] [Closed] (SSHD-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1283. Resolution: Information Provided > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > Time Spent: 10m > Remaining Estimate: 0h > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573069#comment-17573069 ] Lyor Goldstein commented on SSHD-1281: -- {quote} Anyway, SSHD should catch the connection termination and throw an exception {quote} Not if the server does not actually close the connection but only reports it as such. > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionI
[jira] [Closed] (SSHD-1286) how to disable the SSH login and allow only SCP and SFTP
[ https://issues.apache.org/jira/browse/SSHD-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1286. Resolution: Duplicate > how to disable the SSH login and allow only SCP and SFTP > - > > Key: SSHD-1286 > URL: https://issues.apache.org/jira/browse/SSHD-1286 > Project: MINA SSHD > Issue Type: Bug >Reporter: Sreedhar J >Priority: Major > > how do I disable the SSH login and allow only SFTP and SCP calls to > Server ? > i.e allowing below two commands only > sftp -P 1234 user@hostname > scp -P 1234 test1.txt user@hostname > but don't allow the following command exeuction > ssh -p 1234 user@hostname > or SSH login from Putty others -- 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] [Closed] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1281. Resolution: Information Provided > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283) > at > org.apache.sshd.common.util.closeable.Abst
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572781#comment-17572781 ] Lyor Goldstein commented on SSHD-1281: -- {quote} That means your test and mine are not same. {quote} Feels like you are splitting hairs (or clutching at straws), but just to prove my point here: !screenshot-3.png! Attempts {{publickey}} first (fails +twice+ even) and then proceeds to use {{keyboard-interactive}} password - same as your 2.8.0 screenshot > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at >
[jira] [Updated] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1281: - Attachment: screenshot-3.png > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png, screenshot-3.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283) > at > org.apache.sshd.common.util.closeable.Abstrac
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572778#comment-17572778 ] Lyor Goldstein commented on SSHD-1281: -- {quote} I could not build SSHD 2.9.1-SNAPSHOT, which is your test version. {quote} Simple - fork the https://github.com/apache/mina-sshd repository and then run {code}mvn clean install{code} - works like a charm/ {quote} can you attach your snapshot JAR version of sshd-core-2.9.1, sshd-common-2.9.1, sshd-sftp-2.9.1 ? {quote} Sorry, {{2.9.1-SNAPSHOT}} is a +SNAPSHOT+ release - i.e., it is +compiled+ from the sources as I have indicated > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > or
[jira] [Comment Edited] (SSHD-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572588#comment-17572588 ] Lyor Goldstein edited comment on SSHD-1283 at 7/28/22 5:56 PM: --- BTW by your own admission: {quote} terminal client like putty {quote} This is +exactly+ *the same* as {code}ssh @localhost -p {code} so what exactly are you complaining about ? was (Author: lgoldstein): BTW by your own admission: {quote} terminal client like putty {quote} This is +exactly+ *the same* as {code}ssh @localhost -p {code} so why are you complaining ? > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > Time Spent: 10m > Remaining Estimate: 0h > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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] [Commented] (SSHD-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572588#comment-17572588 ] Lyor Goldstein commented on SSHD-1283: -- BTW by your own admission: {quote} terminal client like putty {quote} This is +exactly+ *the same* as {code}ssh @localhost -p {code} so why are you complaining ? > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > Time Spent: 10m > Remaining Estimate: 0h > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1283: Assignee: Lyor Goldstein > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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] [Work started] (SSHD-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1283 started by Lyor Goldstein. > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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] [Commented] (SSHD-1283) Wanted to disable ssh commond while giving scp and sftp support
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572572#comment-17572572 ] Lyor Goldstein commented on SSHD-1283: -- There are +3+ things to take care of if you want to disable remote command execution and/or interactive shell while leaving only SCP and SFTP active. Before calling {{SshServer#start}} # call {{SshServer#setCommandFactory(null)}} # call {{SshServer#setShellFactory(null)}} # create a +new+ {{ScpCommandFactory}} that overrides the methods below and use it instead of the default {code:java} @Override public ShellFactory selectShellFactory(ChannelSession channelSession) throws IOException { return null; } @Override public Command createShell(ChannelSession channel) throws IOException { return null; } {code} In SSHD-1009 we introduced an {{ScpShell}} that provides a +limited+ set of commands in order to use {{WinSCP}} and this shell might be what is providing the interactive capabilities (provide you took care of the other 2 setups). +Note though:+ if you do as I suggested then you will +not+ be able to use {{WinSCP}} with SCP (only with SFTP) as it relies on a +combination+ of SHELL and SCP... > Wanted to disable ssh commond while giving scp and sftp support > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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-1283) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1283: - Summary: Add configurable support for ScpShell usage (was: Wanted to disable ssh commond while giving scp and sftp support) > Add configurable support for ScpShell usage > --- > > Key: SSHD-1283 > URL: https://issues.apache.org/jira/browse/SSHD-1283 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Priority: Major > Attachments: SFTP.zip, image-2022-07-28-17-25-36-368.png > > > Hi Team, > We have implemented sftp server where we are giving SFTP and SCP both > support. > Both are working fine if we connected via winscp or any terminal client like > putty etc. > > But if we use ssh command *ssh @localhost -p * > then it goes to interactive mode and exposes the current program running > directory to do all operations(screenshot shows dir command) (sftp is showing > correct directory as C:/ ) > > !image-2022-07-28-17-25-36-368.png|width=462,height=485! > > So just wanted to check if can we just disable the above ssh command and > still we can use scp and sftp? any help appreciated. > May be this fix is causing the problem? : > https://issues.apache.org/jira/browse/SSHD-1009, > I have attached the sample 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] [Closed] (SSHD-1284) Add configurable support for ScpShell usage
[ https://issues.apache.org/jira/browse/SSHD-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1284. Resolution: Duplicate > Add configurable support for ScpShell usage > --- > > Key: SSHD-1284 > URL: https://issues.apache.org/jira/browse/SSHD-1284 > Project: MINA SSHD > Issue Type: New Feature > Reporter: Lyor Goldstein >Priority: Minor > > The current {{ScpCommand}} factory automatically provides the {{ScpShell}}. > We should make this behavior +configurable+ - the default being enabled so as > to be backward compatible -- 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-1284) Add configurable support for ScpShell usage
Lyor Goldstein created SSHD-1284: Summary: Add configurable support for ScpShell usage Key: SSHD-1284 URL: https://issues.apache.org/jira/browse/SSHD-1284 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein The current {{ScpCommand}} factory automatically provides the {{ScpShell}}. We should make this behavior +configurable+ - the default being enabled so as to be backward compatible -- 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-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572560#comment-17572560 ] Lyor Goldstein commented on SSHD-1281: -- {quote} I am using password based authentication. {quote} So am I: !screenshot-2.png! Everything works +perfectly+ - all I can suggest is that you review your code or setup as you seem to be doing something wrong * mis-configured the server or * mis-configured the client or * +think+ that you are running the same code or * +think+ that you are connecting to the same server with the same code > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > or
[jira] [Updated] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1281: - Attachment: screenshot-2.png > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png, screenshot-2.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283) > at > org.apache.sshd.common.util.closeable.AbstractClose
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572548#comment-17572548 ] Lyor Goldstein commented on SSHD-1281: -- Even from you 2.8.0 screen capture it can be seen that connection fails due to authentication... - I fail to see the difference... > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572545#comment-17572545 ] Lyor Goldstein commented on SSHD-1281: -- {quote} I am using SSHD 2.9.0. Your test is using SSHD 2.9.1-SNAPSHOT {quote} It is identical to 2.9.0 - you can try it yourself - just clone the master repository... > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHD-NoTimeout-2.8.9.PNG, SSHDTimeout.PNG, > screenshot-1.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(Abst
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572349#comment-17572349 ] Lyor Goldstein commented on SSHD-1281: -- No problem (I was using authorized key) !screenshot-1.png! > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHDTimeout.PNG, screenshot-1.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283) > at > org.apache.ssh
[jira] [Updated] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1281: - Attachment: screenshot-1.png > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHDTimeout.PNG, screenshot-1.png > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.sessionClosed(AbstractSessionIoHandler.java:46) > at > org.apache.sshd.common.io.nio2.Nio2Session.doCloseImmediately(Nio2Session.java:283) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:95) > at > org.apach
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572345#comment-17572345 ] Lyor Goldstein commented on SSHD-1281: -- {quote} The root cause looks connection is terminated by SSH server. {quote} I recommend you look at its logs and try to understand why it terminated the connection - perhaps it can shed some light. {quote} The symptom looks authentication is tried even if there is no connection to SSH server. {quote} I doubt that very much - how can authentication be "tried" if there is no connection ? Another thing - we deprecated some KEX methods and/or ciphers - perhaps your server is expected an older setup ? I'll give it a go with my own Bitvise server and see if there is any problem (what version are you using ?) > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHDTimeout.PNG > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main
[jira] [Comment Edited] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572306#comment-17572306 ] Lyor Goldstein edited comment on SSHD-1281 at 7/28/22 8:28 AM: --- All it means is that the authentication "handshake" did no complete within specified/default timeout. I do not see a reason why it should work in 2.8.0 but fail in 2.9.0 - are you sure you are running the +exact+ same code with the +exact+ same server setup ? I recommend making +really sure+ that the server configuration has not changed in any way. In other words, please make 110% percent sure that the +only+ difference is the SSHD version. was (Author: lgoldstein): All it means is that the authentication "handshake" did no complete within specified/default timeout. I do not see a reason why it should work in 2.8.0 but fail in 2.9.0 - are you sure you are running the +exact+ same code with the +exact+ same server setup ? > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHDTimeout.PNG > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSS
[jira] [Commented] (SSHD-1281) ClientSession.auth().verify() is terminated with timeout
[ https://issues.apache.org/jira/browse/SSHD-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572306#comment-17572306 ] Lyor Goldstein commented on SSHD-1281: -- All it means is that the authentication "handshake" did no complete within specified/default timeout. I do not see a reason why it should work in 2.8.0 but fail in 2.9.0 - are you sure you are running the +exact+ same code with the +exact+ same server setup ? > ClientSession.auth().verify() is terminated with timeout > > > Key: SSHD-1281 > URL: https://issues.apache.org/jira/browse/SSHD-1281 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: Java SE 8, Apache NetBeans IDE 12.5, Bitvise SSH Server > 9.23 >Reporter: dgü >Priority: Major > Attachments: SSHDTimeout.PNG > > > Hello! > The following code works successfully in SSHD 2.8.0; but it fails in SSHD > 2.9.0: > {code:java} > final ClientSession clientSession = > SSH_CLIENT.connect(pURI.toString()).verify().getSession(); > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before addPasswordIdentity: " + new > Date(System.currentTimeMillis())); > clientSession.addPasswordIdentity("deneme123"); > try { > Thread.sleep(3000); > } catch (InterruptedException ex) { > > Logger.getLogger(UBSSHDProcessProvider.class.getName()).log(Level.SEVERE, > null, ex); > } > System.out.println("clientSession.getSessionState(): " + > clientSession.getSessionState()); > System.out.println("clientSession.isClosed() : " + > clientSession.isClosed()); > System.out.println("clientSession.isClosing() : " + > clientSession.isClosing()); > System.out.println("clientSession.isOpen() : " + > clientSession.isOpen()); > System.out.println("before auth().verify(): " + new > Date(System.currentTimeMillis())); > clientSession.auth().verify(); > {code} > The output and exception: > {quote}Tem 27, 2022 11:50:19 PM > org.apache.sshd.common.io.DefaultIoServiceFactoryFactory getIoServiceProvider > INFO: No detected/configured IoServiceFactoryFactory using > Nio2ServiceFactoryFactory > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before addPasswordIdentity: Wed Jul 27 23:50:19 EET 2022 > clientSession.getSessionState(): [] > clientSession.isClosed() : false > clientSession.isClosing() : false > clientSession.isOpen() : true > before auth().verify(): Wed Jul 27 23:50:22 EET 2022 > Tem 27, 2022 11:52:20 PM org.apache.sshd.common.session.helpers.SessionHelper > disconnect > INFO: Disconnecting(ClientSessionImpl[deneme@/127.0.0.1:22]): > SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120687/12 ms. > Exception in thread "main" org.apache.sshd.common.SshException: Session is > being closed > at > org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:127) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:39) > at > org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:32) > at > org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:85) > at > com.ubtools.ubutils.system.impl.UBSSHDProcessProvider.getServiceConnection(UBSSHDProcessProvider.java:19) > at > com.ubtools.ubutils.service.UBServiceManager.getServiceConnection(UBServiceManager.java:135) > at com.ubtools.ubutils.UBExec.main(UBExec.java:33) > Caused by: org.apache.sshd.common.SshException: Session is being closed > at > org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSessionImpl.java:169) > at > org.apache.sshd.common.util.closeable.AbstractCloseable.close(AbstractCloseable.java:94) > at > org.apache.sshd.common.session.helpers.AbstractS
[jira] [Updated] (SSHD-1282) Complete support for SFTP "vendor-id" extension
[ https://issues.apache.org/jira/browse/SSHD-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1282: - Labels: SFTP sftp (was: ) > Complete support for SFTP "vendor-id" extension > --- > > Key: SSHD-1282 > URL: https://issues.apache.org/jira/browse/SSHD-1282 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.9.0 >Reporter: Lyor Goldstein >Priority: Minor > Labels: SFTP, sftp > > We currently provide only a client-side extension parser - look into the > possibility of providing it as part of our server extensions as well as > support it as part of a client's extended request. -- 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-1282) Complete support for SFTP "vendor-id" extension
Lyor Goldstein created SSHD-1282: Summary: Complete support for SFTP "vendor-id" extension Key: SSHD-1282 URL: https://issues.apache.org/jira/browse/SSHD-1282 Project: MINA SSHD Issue Type: New Feature Affects Versions: 2.9.0 Reporter: Lyor Goldstein We currently provide only a client-side extension parser - look into the possibility of providing it as part of our server extensions as well as support it as part of a client's extended request. -- 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] [Closed] (SSHD-1280) Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), OpenFuture#cancel behaviours if connection,auhentication,channel open are already done respectively
[ https://issues.apache.org/jira/browse/SSHD-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1280. Resolution: Information Provided > Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), > OpenFuture#cancel behaviours if connection,auhentication,channel open are > already done respectively > - > > Key: SSHD-1280 > URL: https://issues.apache.org/jira/browse/SSHD-1280 > Project: MINA SSHD > Issue Type: Documentation >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü >Priority: Major > > Hello! > > {code:java} > /** > * Cancels the connection attempt and notifies all threads waiting for > this future. > */ > void cancel(); > {code} > Ref: > [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/ConnectFuture.java] > {code:java} > /** > * Cancels the authentication attempt and notifies all threads waiting > for this future. > */ > void cancel(); > {code} > Ref: > [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/AuthFuture.java] > According to my tests; > * ConnectFuture#cancel() cancels client session connection attempt only if > connection is not established yet. If connection is established, it doesn't > cancel. > * AuthFuture#cancel() cancels client authentication attempt only if > authentication is not completed yet. If authentication is completed, it > doesn't cancel. > are these behaviours are expected ? If so, it is possible to update the > documentation to rely on these behaviours ? > Thanks in advance! -- 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-1280) Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), OpenFuture#cancel behaviours if connection,auhentication,channel open are already done respectively
[ https://issues.apache.org/jira/browse/SSHD-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17569606#comment-17569606 ] Lyor Goldstein commented on SSHD-1280: -- I disagree with the need to re-phrase the documentation - I believe it defines +exactly+ the method's behavior. Obviously, if a channel is already open then cancelling an {{OpenFuture}} should have no effect on it. This is a slippery slope - why not also request to document the fact that if the session has been closed, or the channel has been closed 1 hour ago then {{OpenFuture#cancel}} has no effect. No offenses, but one does not document that 2+2 = 4... > Clarification of ConnectFuture#cancel(), AuthFuture#cancel(), > OpenFuture#cancel behaviours if connection,auhentication,channel open are > already done respectively > - > > Key: SSHD-1280 > URL: https://issues.apache.org/jira/browse/SSHD-1280 > Project: MINA SSHD > Issue Type: Documentation >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü >Priority: Major > > Hello! > > {code:java} > /** > * Cancels the connection attempt and notifies all threads waiting for > this future. > */ > void cancel(); > {code} > Ref: > [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/ConnectFuture.java] > {code:java} > /** > * Cancels the authentication attempt and notifies all threads waiting > for this future. > */ > void cancel(); > {code} > Ref: > [https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/future/AuthFuture.java] > According to my tests; > * ConnectFuture#cancel() cancels client session connection attempt only if > connection is not established yet. If connection is established, it doesn't > cancel. > * AuthFuture#cancel() cancels client authentication attempt only if > authentication is not completed yet. If authentication is completed, it > doesn't cancel. > are these behaviours are expected ? If so, it is possible to update the > documentation to rely on these behaviours ? > Thanks in advance! -- 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-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[ https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1279: Assignee: Lyor Goldstein > Is it possible to detect Input protocol is scp and sftp at provider level? > -- > > Key: SSHD-1279 > URL: https://issues.apache.org/jira/browse/SSHD-1279 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > > Hi Team, > For sftp server side I need to check whether the input protocol is SCP and > SFTP. Can any one help me how to do at the FileSystemProvider level or any > other option? > ~Sandeep -- 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-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[ https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1279. -- Resolution: Information Provided > Is it possible to detect Input protocol is scp and sftp at provider level? > -- > > Key: SSHD-1279 > URL: https://issues.apache.org/jira/browse/SSHD-1279 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep > Assignee: Lyor Goldstein >Priority: Major > > Hi Team, > For sftp server side I need to check whether the input protocol is SCP and > SFTP. Can any one help me how to do at the FileSystemProvider level or any > other option? > ~Sandeep -- 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-1279) Is it possible to detect Input protocol is scp and sftp at provider level?
[ https://issues.apache.org/jira/browse/SSHD-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17569603#comment-17569603 ] Lyor Goldstein commented on SSHD-1279: -- Easy - {{FileSystemProvider}} cannot be implemented over standard SCP as the protocol lacks most of the required primitives for its implementation. One could implement it using SCP + SHELL, but not over pure SCP. Therefore, if it is a functional {{FileSystemProvider}} then it +must+ be SFTP. > Is it possible to detect Input protocol is scp and sftp at provider level? > -- > > Key: SSHD-1279 > URL: https://issues.apache.org/jira/browse/SSHD-1279 > Project: MINA SSHD > Issue Type: Question >Reporter: Sandeep >Priority: Major > > Hi Team, > For sftp server side I need to check whether the input protocol is SCP and > SFTP. Can any one help me how to do at the FileSystemProvider level or any > other option? > ~Sandeep -- 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-1278) How to release client connection resources after connection timeout occurs ?
[ https://issues.apache.org/jira/browse/SSHD-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566933#comment-17566933 ] Lyor Goldstein commented on SSHD-1278: -- {quote} It would be great if timeout occurs, resource is automatically closed by SSHD. {quote} I don't know what you mean about "resource" - but the session is automatically closed if failed to connect or authenticate on time. If it is your own "resource" then I believe it is +your+ responsibility to release it. Furthermore, if the "timeout" you mention has to do with your own logic - then (again) I believe it is +your+ responsibility to take care of it. {quote} ConnectFuture#cancel() doesn't close created session. {quote} I believe it does - provided the session has not already been established already - at which time you need to close the session yourself. > How to release client connection resources after connection timeout occurs ? > > > Key: SSHD-1278 > URL: https://issues.apache.org/jira/browse/SSHD-1278 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > I want to release client connection resources after connection timeout occurs > ? > This is the code: > {code:java} > ConnectFuture connectFuture = sshClient.connect(uri.toString()); > try { > //connectFuture.isConnected() returns false > connectFuture.verify(timeout); > } catch (IOException e) { > //connectFuture.isConnected() returns true > connectFuture.cancel(); > //connectFuture.isCanceled() returns false > //connectFuture.isConnected() returns true > throw e; > } > {code} > I guess there is a race condition between client connection and > {{ConnectFuture#isConnected()}}. > For example, this code may be wrong: > {code:java} > if (!connectFuture.isConnected()) { > //connectFuture.isConnected() may return true > } > {code} > In my case, session is connected after timeout. > How can I be sure that client is still not connected and release its > resources after connection timeout occurs ? > Thanks in advance! -- 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] [Closed] (SSHD-1274) UserInteraction Problem
[ https://issues.apache.org/jira/browse/SSHD-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1274. Resolution: Abandoned > UserInteraction Problem > --- > > Key: SSHD-1274 > URL: https://issues.apache.org/jira/browse/SSHD-1274 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 >Reporter: Cheung >Priority: Major > Fix For: 2.8.0 > > > I used the sshd client。 I need to change my password when I logged in for the > first time,the interaction is success in xshell。There are three complete > interactions: > 1.Enter a new password > 2.Confirm new password > 3.connected and enter the service > But when i use sshd clent, i just can received first time interactive from > service。i use the > org.apache.sshd.client.auth.keyboard.UserInteraction#interactive to received > prompt from service。The clientSession connect is success,but authFure done is > false and the opeFuture of shellChannel is false。 > I try to read byte of passowrd to shellChannel‘s inputStream,it's not work。 > How can i send the newPassword to service and received interactive from > service after first time。 > -- 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-1275) Remote process is still available after ChannelExec.close(true).awaitUninterruptibly()
[ https://issues.apache.org/jira/browse/SSHD-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1275. -- Resolution: Information Provided > Remote process is still available after > ChannelExec.close(true).awaitUninterruptibly() > -- > > Key: SSHD-1275 > URL: https://issues.apache.org/jira/browse/SSHD-1275 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > If I close channel immediately by > {{{}org.apache.sshd.client.channel.ChannelExec.close(true).awaitUninterruptibly(){}}}, > the remote process is not terminated and > {{org.apache.sshd.client.channel.ChannelExec#getExitStatus()}} returns > {{{}null{}}}. > Even if I test with _Thread.sleep(60*1000)_ after channel close, the problem > still happens. The problem doesn't happen when channel is closed gracefully. > is this expected behaviour ? > > Thanks in advance! -- 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-1275) Remote process is still available after ChannelExec.close(true).awaitUninterruptibly()
[ https://issues.apache.org/jira/browse/SSHD-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566437#comment-17566437 ] Lyor Goldstein commented on SSHD-1275: -- This is very thorough but I fail to see how it is related to SSH or the MINA code... > Remote process is still available after > ChannelExec.close(true).awaitUninterruptibly() > -- > > Key: SSHD-1275 > URL: https://issues.apache.org/jira/browse/SSHD-1275 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Priority: Major > > Hello! > If I close channel immediately by > {{{}org.apache.sshd.client.channel.ChannelExec.close(true).awaitUninterruptibly(){}}}, > the remote process is not terminated and > {{org.apache.sshd.client.channel.ChannelExec#getExitStatus()}} returns > {{{}null{}}}. > Even if I test with _Thread.sleep(60*1000)_ after channel close, the problem > still happens. The problem doesn't happen when channel is closed gracefully. > is this expected behaviour ? > > Thanks in advance! -- 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-1275) Remote process is still available after ChannelExec.close(true).awaitUninterruptibly()
[ https://issues.apache.org/jira/browse/SSHD-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1275: Assignee: Lyor Goldstein > Remote process is still available after > ChannelExec.close(true).awaitUninterruptibly() > -- > > Key: SSHD-1275 > URL: https://issues.apache.org/jira/browse/SSHD-1275 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > If I close channel immediately by > {{{}org.apache.sshd.client.channel.ChannelExec.close(true).awaitUninterruptibly(){}}}, > the remote process is not terminated and > {{org.apache.sshd.client.channel.ChannelExec#getExitStatus()}} returns > {{{}null{}}}. > Even if I test with _Thread.sleep(60*1000)_ after channel close, the problem > still happens. The problem doesn't happen when channel is closed gracefully. > is this expected behaviour ? > > Thanks in advance! -- 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-1278) How to release client connection resources after connection timeout occurs ?
[ https://issues.apache.org/jira/browse/SSHD-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566397#comment-17566397 ] Lyor Goldstein commented on SSHD-1278: -- {quote} I can not use {{try-with-resource}} block since the logic is not limited in {{try-with-resource}} block. {quote} Not a problem: {code:java} ClientSession session = client.connect(...uri...).verify(CONNECT_TIMEOUT).getSession(); try { session.addPasswordIdentity(getCurrentTestName()); // or add key identity session.auth().verify(AUTH_TIMEOUT); handOverTheSession(session); // whoever takes over the session should close it once done session = null;// prevent auto-close at finally clause } finally { if (session != null) { session.close() } } {code} And you can even do it +asynchronously+ - though more complex: {code:java} ConnectFuture future = client.connect(...uri...); future.addListener(f -> { if (f.isConnected()) { authenticateSession(f,getSession());// can do the same aysnchronous authentication - make sure to close the session if auth. fails } else { f.getException(); // the problem } }); {code} > How to release client connection resources after connection timeout occurs ? > > > Key: SSHD-1278 > URL: https://issues.apache.org/jira/browse/SSHD-1278 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > I want to release client connection resources after connection timeout occurs > ? > This is the code: > {code:java} > ConnectFuture connectFuture = sshClient.connect(uri.toString()); > try { > //connectFuture.isConnected() returns false > connectFuture.verify(timeout); > } catch (IOException e) { > //connectFuture.isConnected() returns true > connectFuture.cancel(); > //connectFuture.isCanceled() returns false > //connectFuture.isConnected() returns true > throw e; > } > {code} > I guess there is a race condition between client connection and > {{ConnectFuture#isConnected()}}. > For example, this code may be wrong: > {code:java} > if (!connectFuture.isConnected()) { > //connectFuture.isConnected() may return true > } > {code} > In my case, session is connected after timeout. > How can I be sure that client is still not connected and release its > resources after connection timeout occurs ? > Thanks in advance! -- 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] [Closed] (SSHD-1278) How to release client connection resources after connection timeout occurs ?
[ https://issues.apache.org/jira/browse/SSHD-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1278. Resolution: Information Provided > How to release client connection resources after connection timeout occurs ? > > > Key: SSHD-1278 > URL: https://issues.apache.org/jira/browse/SSHD-1278 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > I want to release client connection resources after connection timeout occurs > ? > This is the code: > {code:java} > ConnectFuture connectFuture = sshClient.connect(uri.toString()); > try { > //connectFuture.isConnected() returns false > connectFuture.verify(timeout); > } catch (IOException e) { > //connectFuture.isConnected() returns true > connectFuture.cancel(); > //connectFuture.isCanceled() returns false > //connectFuture.isConnected() returns true > throw e; > } > {code} > I guess there is a race condition between client connection and > {{ConnectFuture#isConnected()}}. > For example, this code may be wrong: > {code:java} > if (!connectFuture.isConnected()) { > //connectFuture.isConnected() may return true > } > {code} > In my case, session is connected after timeout. > How can I be sure that client is still not connected and release its > resources after connection timeout occurs ? > Thanks in advance! -- 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-1278) How to release client connection resources after connection timeout occurs ?
[ https://issues.apache.org/jira/browse/SSHD-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17565939#comment-17565939 ] Lyor Goldstein commented on SSHD-1278: -- I don't understand the code and what you are trying to achieve - it does seem though that you have not read the documentation carefully. In any case, here is the recommended way to connect and authenticate using {{try-with-resource}}: {code:java} try (ClientSession session = client.connect(...uri...).verify(CONNECT_TIMEOUT).getSession()) { session.addPasswordIdentity(getCurrentTestName()); // or add key identity session.auth().verify(AUTH_TIMEOUT); } {code} I fail to see the need to use the {{ConnectFuture}} or query it for {{isConnected}}. As far as releasing the connection - there is no need - if {{verify}} fails, it throws an exception which causes the {{try-with-resource}} block to exit and thus release whatever needs to be released. As far as your code is concerned - it behaves as it should: {code:java} ConnectFuture connectFuture = sshClient.connect(uri.toString()); try { //connectFuture.isConnected() returns false - Of course it does, only when verify returns the connection is established connectFuture.verify(timeout); } catch (IOException e) { //connectFuture.isConnected() returns true - so what ? there was an exception so obviously the connection is doomed. Furthermore, the disconnect is ASYNCHRONOUS - so you might have sampled isConnected too soon connectFuture.cancel(); //connectFuture.isCanceled() returns false - ASYNCHRONOUS (!) //connectFuture.isConnected() returns true - ASYNCHRONOUS (!) throw e; } {code} Please documentation carefully (again, and again, and again) - and make sure to look at the code samples there for recommended usage. Try to adhere to the coding patterns shown in the documentation unless there is very good justification to do otherwise. Also, I highly recommend to look at you test code as it contains 100's of examples of possible use cases - even unusual ones. > How to release client connection resources after connection timeout occurs ? > > > Key: SSHD-1278 > URL: https://issues.apache.org/jira/browse/SSHD-1278 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 > Reporter: dgü >Assignee: Lyor Goldstein >Priority: Major > > Hello! > I want to release client connection resources after connection timeout occurs > ? > This is the code: > {code:java} > ConnectFuture connectFuture = sshClient.connect(uri.toString()); > try { > //connectFuture.isConnected() returns false > connectFuture.verify(timeout); > } catch (IOException e) { > //connectFuture.isConnected() returns true > connectFuture.cancel(); > //connectFuture.isCanceled() returns false > //connectFuture.isConnected() returns true > throw e; > } > {code} > I guess there is a race condition between client connection and > {{ConnectFuture#isConnected()}}. > For example, this code may be wrong: > {code:java} > if (!connectFuture.isConnected()) { > //connectFuture.isConnected() may return true > } > {code} > In my case, session is connected after timeout. > How can I be sure that client is still not connected and release its > resources after connection timeout occurs ? > Thanks in advance! -- 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-1278) How to release client connection resources after connection timeout occurs ?
[ https://issues.apache.org/jira/browse/SSHD-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1278: Assignee: Lyor Goldstein > How to release client connection resources after connection timeout occurs ? > > > Key: SSHD-1278 > URL: https://issues.apache.org/jira/browse/SSHD-1278 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Major > > Hello! > I want to release client connection resources after connection timeout occurs > ? > This is the code: > {code:java} > ConnectFuture connectFuture = sshClient.connect(uri.toString()); > try { > //connectFuture.isConnected() returns false > connectFuture.verify(timeout); > } catch (IOException e) { > //connectFuture.isConnected() returns true > connectFuture.cancel(); > //connectFuture.isCanceled() returns false > //connectFuture.isConnected() returns true > throw e; > } > {code} > I guess there is a race condition between client connection and > {{ConnectFuture#isConnected()}}. > For example, this code may be wrong: > {code:java} > if (!connectFuture.isConnected()) { > //connectFuture.isConnected() may return true > } > {code} > In my case, session is connected after timeout. > How can I be sure that client is still not connected and release its > resources after connection timeout occurs ? > Thanks in advance! -- 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-1275) Remote process is still available after ChannelExec.close(true).awaitUninterruptibly()
[ https://issues.apache.org/jira/browse/SSHD-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17565114#comment-17565114 ] Lyor Goldstein commented on SSHD-1275: -- {quote} I don't have a test environment to debug which kind of signal is sent to remote application. But, I expect SIGKILL (kill -9) has to be sent to remote process to terminate/kill it immediately. It looks remote application doesn't receive SIGKILL to be terminated. {quote} The {{ChannelExec}} protocol does not send any SIGKILL or an equivalent of it when it is closed. {quote} Even if remote application is not terminated by immediate channel close, it's terminated after I exit from the client application. That means a messaging happens between client and remote process. I am not sure if such messaging can happen by immediate channel close without exiting the client application. {quote} To best of my knowledge of the SSH protocol(s) and re-checking the source code there is no such messaging... > Remote process is still available after > ChannelExec.close(true).awaitUninterruptibly() > -- > > Key: SSHD-1275 > URL: https://issues.apache.org/jira/browse/SSHD-1275 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Priority: Major > > Hello! > If I close channel immediately by > {{{}org.apache.sshd.client.channel.ChannelExec.close(true).awaitUninterruptibly(){}}}, > the remote process is not terminated and > {{org.apache.sshd.client.channel.ChannelExec#getExitStatus()}} returns > {{{}null{}}}. > Even if I test with _Thread.sleep(60*1000)_ after channel close, the problem > still happens. The problem doesn't happen when channel is closed gracefully. > is this expected behaviour ? > > Thanks in advance! -- 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-1276) Add support for merged inverted output and error streams of remote process
[ https://issues.apache.org/jira/browse/SSHD-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1276. -- Fix Version/s: 2.9.0 Resolution: Fixed > Add support for merged inverted output and error streams of remote process > -- > > Key: SSHD-1276 > URL: https://issues.apache.org/jira/browse/SSHD-1276 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Minor > Fix For: 2.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Hello! > I want to merge output and error streams of remote process as > {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does. > If I set output and error streams; > {quote}channelExec.setOut(mergedOutputStream); > channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return {{{}null{}}}. > If I don't set output and error streams; > {quote}//channelExec.setOut(mergedOutputStream); > //channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return not {{{}null{}}}. But, streams are not merged. > How can I merge output and error streams of remote process ? > Thanks in advance! -- 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-1276) Add support for merged inverted output and error streams of remote process
[ https://issues.apache.org/jira/browse/SSHD-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563893#comment-17563893 ] Lyor Goldstein commented on SSHD-1276: -- I am adding STDERR redirection support feature, but it will be available whenever we release the +next+ version. Meanwhile, if you can't wait that long (probably a few weeks), then you can write a "bridging" stream that reads from +both+ the inverted streams somehow. A doable challenge IMO, but beyond the scope of this project - so god speed and good luck,. > Add support for merged inverted output and error streams of remote process > -- > > Key: SSHD-1276 > URL: https://issues.apache.org/jira/browse/SSHD-1276 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 > Reporter: dgü >Assignee: Lyor Goldstein >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Hello! > I want to merge output and error streams of remote process as > {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does. > If I set output and error streams; > {quote}channelExec.setOut(mergedOutputStream); > channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return {{{}null{}}}. > If I don't set output and error streams; > {quote}//channelExec.setOut(mergedOutputStream); > //channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return not {{{}null{}}}. But, streams are not merged. > How can I merge output and error streams of remote process ? > Thanks in advance! -- 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-1275) Remote process is still available after ChannelExec.close(true).awaitUninterruptibly()
[ https://issues.apache.org/jira/browse/SSHD-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563889#comment-17563889 ] Lyor Goldstein commented on SSHD-1275: -- {quote} If close {{ChannelExec}} immediately, the remote application is not terminated/died. I guess since it is never terminated, there is no exit value. {quote} Seems like this question should be posed to whoever wrote the remote process... {quote} But, is it expected behaviour not to terminate a remote process by org.apache.sshd.client.channel.ChannelExec#close(true) ? {quote} All {{ChannelExec#close}} does is close the +client+ channel - MINA SSHD has no control over what the peer server does or does not do as far as the remote process is concerned so while I may agree with you that the +recommended+ behavior is as you described, it is not within the scope of this project to answer this. Again, seems like this question should be posed to whoever wrote the remote process... > Remote process is still available after > ChannelExec.close(true).awaitUninterruptibly() > -- > > Key: SSHD-1275 > URL: https://issues.apache.org/jira/browse/SSHD-1275 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Priority: Major > > Hello! > If I close channel immediately by > {{{}org.apache.sshd.client.channel.ChannelExec.close(true).awaitUninterruptibly(){}}}, > the remote process is not terminated and > {{org.apache.sshd.client.channel.ChannelExec#getExitStatus()}} returns > {{{}null{}}}. > Even if I test with _Thread.sleep(60*1000)_ after channel close, the problem > still happens. The problem doesn't happen when channel is closed gracefully. > is this expected behaviour ? > > Thanks in advance! -- 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-1276) Add support for merged inverted output and error streams of remote process
[ https://issues.apache.org/jira/browse/SSHD-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563643#comment-17563643 ] Lyor Goldstein commented on SSHD-1276: -- [~twolf] can you take a look at https://github.com/apache/mina-sshd/pull/231 ? Thx > Add support for merged inverted output and error streams of remote process > -- > > Key: SSHD-1276 > URL: https://issues.apache.org/jira/browse/SSHD-1276 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Assignee: Lyor Goldstein >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Hello! > I want to merge output and error streams of remote process as > {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does. > If I set output and error streams; > {quote}channelExec.setOut(mergedOutputStream); > channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return {{{}null{}}}. > If I don't set output and error streams; > {quote}//channelExec.setOut(mergedOutputStream); > //channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return not {{{}null{}}}. But, streams are not merged. > How can I merge output and error streams of remote process ? > Thanks in advance! -- 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-1276) Add support for to merged output and error streams of remote process
[ https://issues.apache.org/jira/browse/SSHD-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1276: - Summary: Add support for to merged output and error streams of remote process (was: How to merge output and error streams of remote process ?) > Add support for to merged output and error streams of remote process > > > Key: SSHD-1276 > URL: https://issues.apache.org/jira/browse/SSHD-1276 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü >Priority: Minor > > Hello! > I want to merge output and error streams of remote process as > {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does. > If I set output and error streams; > {quote}channelExec.setOut(mergedOutputStream); > channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return {{{}null{}}}. > If I don't set output and error streams; > {quote}//channelExec.setOut(mergedOutputStream); > //channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return not {{{}null{}}}. But, streams are not merged. > How can I merge output and error streams of remote process ? > Thanks in advance! -- 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] [Work started] (SSHD-1276) Add support for merged inverted output and error streams of remote process
[ https://issues.apache.org/jira/browse/SSHD-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1276 started by Lyor Goldstein. > Add support for merged inverted output and error streams of remote process > -- > > Key: SSHD-1276 > URL: https://issues.apache.org/jira/browse/SSHD-1276 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.8.0 > Environment: Java SE 8, Apache NetBeans IDE 8.2 >Reporter: dgü > Assignee: Lyor Goldstein >Priority: Minor > > Hello! > I want to merge output and error streams of remote process as > {{java.lang.ProcessBuilder#redirectErrorStream(true)}} does. > If I set output and error streams; > {quote}channelExec.setOut(mergedOutputStream); > channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return {{{}null{}}}. > If I don't set output and error streams; > {quote}//channelExec.setOut(mergedOutputStream); > //channelExec.setErr(mergedOutputStream); > channelExec.open.verify(); > {quote} > Then, {{ChannelExec#getInvertedOut()}} and {{ChannelExec#getInvertedErr()}} > return not {{{}null{}}}. But, streams are not merged. > How can I merge output and error streams of remote process ? > Thanks in advance! -- 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