[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 mess
[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 are other
[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=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=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=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=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=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=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=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=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=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=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 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 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 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 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=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 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 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=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=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=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=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=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=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=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=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=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=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=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=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 means that it attempts to receive packets that exceed 3
[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=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=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.apache.sshd.common.session.helpers.AbstractSe
[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=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(AbstractSessionIoHandler.java:46)
>
[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=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.common.
[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=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.AbstractSessionIoHandler.sessionClosed(Ab
[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=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
> org.apache.sshd.common.util.closeable
[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=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
>
[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=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=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=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=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
> org.apache.sshd.client.session.ClientSessionImpl.preClose(ClientSession
[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.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=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.sshd.common.io.nio2.Nio2
[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=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(AbstractSessionIoHandler.java:46)
> 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=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.sshd.common.util.closeable.Abstrac
[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=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(UBExec.j
[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=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.UB
[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=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.AbstractSessionIoHandler.sessionCl
[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=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=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=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=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=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=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=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=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=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=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
