[jira] [Assigned] (SSHD-929) Separate listener for deleting directory in SFTP

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-929:
---

Assignee: Goldstein Lyor

> Separate listener for deleting directory in SFTP
> 
>
> Key: SSHD-929
> URL: https://issues.apache.org/jira/browse/SSHD-929
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Subramaniajeeva
>Assignee: Goldstein Lyor
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Right now listener for deletion of file and directory is common. This makes 
> it difficult to find whether directory / file has been removed.
> The path passed to `removed` function in SftpEventListener will not tell if 
> the deleted path was a directory or file. `Files.isDirectory(path)` will 
> return false, as the derectory doesn't exist.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-927) SFTP put fails terminating the connection if the remote file exists

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-927:
-

Can you also provide log messages from the Java side (the call stack is not 
informative enough) ?

> SFTP put fails terminating the connection if the remote file exists
> ---
>
> Key: SSHD-927
> URL: https://issues.apache.org/jira/browse/SSHD-927
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0, 2.2.0
> Environment: Java:
> C:\Program Files\Java\jdk1.8.0_201\bin>java -version
> java version "1.8.0_201"
> Java(TM) SE Runtime Environment (build 1.8.0_201-b26)
> Java HotSpot(TM) 64-Bit Server VM (build 25.201-b26, mixed mode)
> Apache SSHD : 2.1.0
> C:\temp>sftp2 --version
> sftp2: Tectia Client 6.4.14 on x86-pc-windows
> Build: 26
> Product: Tectia Client
> License type: commercial
> Copyright (C) SSH Communications Security Corporation.
> This software is protected by international copyright laws.
> All rights reserved.
> This product includes software developed by the OpenSSL Project
> for use in the OpenSSL Toolkit. (http://www.openssl.org/)
> SFT API: 2.0.3 (build 6.4.14.26)
>Reporter: Logan
>Priority: Major
> Attachments: thread-callstack.txt
>
>
> Sftp put fails if the file already exists on the sftp server, terminating the 
> sfp session immediately.Below is the simple configuration to reproduce
>  
> {code:java}
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort();
> sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider());
> sshd.setSubsystemFactories(Arrays.asList(new SftpSubsystemFactory()));
> sshd.setFileSystemFactory(new VirtualFileSystemFactory(new 
> File("C:/temp").toPath()));
> sshd.setPasswordAuthenticator(AcceptAllPasswordAuthenticator.INSTANCE);
> sshd.start();
> {code}
>  
> {noformat}
> C:\temp>sftp2 test@localhost#
> Host key for the host "localhost#" not found from database.
> The fingerprint of the host public key is:
> Babble: "xodec-damen-ripeg-hehuh-venep-pebys-zureg-rynit-mypiz-byheh-zixax"
> RFC4716: "1d:4f:c2:a4:fe:58:93:61:fe:44:69:26:f2:41:34:f7"
> You can get a public key's fingerprint by running
> % ssh-keygen-g3 -F publickey.pub
> on the key file.
> Please select how you want to proceed.
>  cancel) Cancel the connection.
>  once) Proceed with the connection but do not save the key.
>  save) Proceed with the connection and save the key for future use.
> Please select one (cancel, once, save): once
> test@localhost#'s password:
> Remote system type is POSIX.
> sftp> put ndp46-kb4483451-x64_41ba9b8a814351a318e78e4e1c02adc7e9fff67a.exe
> Error: Connection lost.
> {noformat}
> Upon Debugging I found the SftpSystem is terminated because the file channel 
> received close command ( see attached )
> Added event listener to see reading and read method are called but no 
> writing/write methods are never called.
>  
> This can reproducible with v2.2.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-927) SFTP put fails terminating the connection if the remote file exists

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-927:
-

I do see something "strange" so to speak: the example is using a Windows client 
called {{sftp2}} - can you provide some details about this client ? Where can I 
download/install it in order to see if it behaves in some unexpected manner ?

Very strange - SFTP is one of the most stable subsystem implementations we have 
- at least as far as compatibility with Linux, Putty and WinSCP - that's why I 
am curious about this {{sftp2}}. BTW, have you tried WinSCP with the Java 
server ? Should work...


> SFTP put fails terminating the connection if the remote file exists
> ---
>
> Key: SSHD-927
> URL: https://issues.apache.org/jira/browse/SSHD-927
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0, 2.2.0
> Environment: Java:
> C:\Program Files\Java\jdk1.8.0_201\bin>java -version
> java version "1.8.0_201"
> Java(TM) SE Runtime Environment (build 1.8.0_201-b26)
> Java HotSpot(TM) 64-Bit Server VM (build 25.201-b26, mixed mode)
> Apache SSHD : 2.1.0
> C:\temp>sftp2 --version
> sftp2: Tectia Client 6.4.14 on x86-pc-windows
> Build: 26
> Product: Tectia Client
> License type: commercial
> Copyright (C) SSH Communications Security Corporation.
> This software is protected by international copyright laws.
> All rights reserved.
> This product includes software developed by the OpenSSL Project
> for use in the OpenSSL Toolkit. (http://www.openssl.org/)
> SFT API: 2.0.3 (build 6.4.14.26)
>Reporter: Logan
>Priority: Major
> Attachments: thread-callstack.txt
>
>
> Sftp put fails if the file already exists on the sftp server, terminating the 
> sfp session immediately.Below is the simple configuration to reproduce
>  
> {code:java}
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort();
> sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider());
> sshd.setSubsystemFactories(Arrays.asList(new SftpSubsystemFactory()));
> sshd.setFileSystemFactory(new VirtualFileSystemFactory(new 
> File("C:/temp").toPath()));
> sshd.setPasswordAuthenticator(AcceptAllPasswordAuthenticator.INSTANCE);
> sshd.start();
> {code}
>  
> {noformat}
> C:\temp>sftp2 test@localhost#
> Host key for the host "localhost#" not found from database.
> The fingerprint of the host public key is:
> Babble: "xodec-damen-ripeg-hehuh-venep-pebys-zureg-rynit-mypiz-byheh-zixax"
> RFC4716: "1d:4f:c2:a4:fe:58:93:61:fe:44:69:26:f2:41:34:f7"
> You can get a public key's fingerprint by running
> % ssh-keygen-g3 -F publickey.pub
> on the key file.
> Please select how you want to proceed.
>  cancel) Cancel the connection.
>  once) Proceed with the connection but do not save the key.
>  save) Proceed with the connection and save the key for future use.
> Please select one (cancel, once, save): once
> test@localhost#'s password:
> Remote system type is POSIX.
> sftp> put ndp46-kb4483451-x64_41ba9b8a814351a318e78e4e1c02adc7e9fff67a.exe
> Error: Connection lost.
> {noformat}
> Upon Debugging I found the SftpSystem is terminated because the file channel 
> received close command ( see attached )
> Added event listener to see reading and read method are called but no 
> writing/write methods are never called.
>  
> This can reproducible with v2.2.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-925 at 6/23/19 10:15 AM:
---

When receiving a directory, again it is the *receiver* that decides where the 
incoming files (and/or sub-directories) will be placed, so it does not seem 
that a malicious sender can clobber unintended files. The same validity checks 
could be applied, although matching is even more difficult - especially if we 
have wildcards involved.


was (Author: lgoldstein):
When receiving a directory, again it is the *client* that decides where the 
incoming files (and/or sub-directories) will be placed, so it does not seem 
that a malicious server can clobber unintended files. The same validity checks 
could be applied, although matching is even more difficult - especially if we 
have wildcards involved.

> See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so
> 
>
> Key: SSHD-925
> URL: https://issues.apache.org/jira/browse/SSHD-925
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: scp, security-issue
>
> From [OpenSSH version 8.0 release 
> notes|https://www.openssh.com/txt/release-8.0]
> {quote}
> This release contains mitigation for a weakness in the scp(1) tool and 
> protocol (CVE-2019-6111): when copying files from a remote system to a local 
> directory, scp(1) did not verify that the filenames that the server sent 
> matched those requested by the client. This could allow a hostile server to 
> create or clobber unexpected local files with attacker-controlled content.
> {quote}
> If indeed this vulnerability exists then also note the following
> {quote}
> The scp protocol relies on the remote shell for wildcard expansion, so there 
> is no infallible way for the client's wildcard matching to perfectly reflect 
> the server's. If there is a difference between client and server wildcard 
> expansion, the client may refuse files from the server. For this reason, we 
> have provided a new "-T" flag to scp that disables these client-side checks 
> at the risk of reintroducing the attack described above.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-925 at 6/23/19 10:14 AM:
---

When downloading a single file, it seems that the vulnerability does not exist 
since the receiver determines the local {{Path}} regardless of the name 
reported reported by the sender when data is actually received. In this 
context, perhaps we should add a (configurable) validity check that the name 
reported by the sender matches the one requested by the receiver. Note though 
that such a check is not trivial - e.g., do we check only the file name or the 
entire relative path ?


was (Author: lgoldstein):
When downloading a single file, it seems that the vulnerability does not exist 
since the client determines the local {{Path}} regardless of the name reported 
reported by the server when data is actually received. In this context, perhaps 
we should add a (configurable) validity check that the name reported by the 
server matches the one requested by the client. Note though that such a check 
is not trivial - e.g., do we check only the file name or the entire relative 
path ?

> See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so
> 
>
> Key: SSHD-925
> URL: https://issues.apache.org/jira/browse/SSHD-925
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: scp, security-issue
>
> From [OpenSSH version 8.0 release 
> notes|https://www.openssh.com/txt/release-8.0]
> {quote}
> This release contains mitigation for a weakness in the scp(1) tool and 
> protocol (CVE-2019-6111): when copying files from a remote system to a local 
> directory, scp(1) did not verify that the filenames that the server sent 
> matched those requested by the client. This could allow a hostile server to 
> create or clobber unexpected local files with attacker-controlled content.
> {quote}
> If indeed this vulnerability exists then also note the following
> {quote}
> The scp protocol relies on the remote shell for wildcard expansion, so there 
> is no infallible way for the client's wildcard matching to perfectly reflect 
> the server's. If there is a difference between client and server wildcard 
> expansion, the client may refuse files from the server. For this reason, we 
> have provided a new "-T" flag to scp that disables these client-side checks 
> at the risk of reintroducing the attack described above.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-925 at 6/23/19 9:51 AM:
--

When receiving a directory, again it is the *client* that decides where the 
incoming files (and/or sub-directories) will be placed, so it does not seem 
that a malicious server can clobber unintended files. The same validity checks 
could be applied, although matching is even more difficult - especially if we 
have wildcards involved.


was (Author: lgoldstein):
When receiving a directory, again it is the *client* that decides where the 
incoming files (and/or sub-directories) will be placed, so it does not seem 
that a malicious server can clobber unintended files. The same validity checks 
could be applied, although matching is even more difficult - especially if we 
have wildcards involved.

> See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so
> 
>
> Key: SSHD-925
> URL: https://issues.apache.org/jira/browse/SSHD-925
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: scp, security-issue
>
> From [OpenSSH version 8.0 release 
> notes|https://www.openssh.com/txt/release-8.0]
> {quote}
> This release contains mitigation for a weakness in the scp(1) tool and 
> protocol (CVE-2019-6111): when copying files from a remote system to a local 
> directory, scp(1) did not verify that the filenames that the server sent 
> matched those requested by the client. This could allow a hostile server to 
> create or clobber unexpected local files with attacker-controlled content.
> {quote}
> If indeed this vulnerability exists then also note the following
> {quote}
> The scp protocol relies on the remote shell for wildcard expansion, so there 
> is no infallible way for the client's wildcard matching to perfectly reflect 
> the server's. If there is a difference between client and server wildcard 
> expansion, the client may refuse files from the server. For this reason, we 
> have provided a new "-T" flag to scp that disables these client-side checks 
> at the risk of reintroducing the attack described above.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-925:
-

When receiving a directory, again it is the *client* that decides where the 
incoming files (and/or sub-directories) will be placed, so it does not seem 
that a malicious server can clobber unintended files. The same validity checks 
could be applied, although matching is even more difficult - especially if we 
have wildcards involved.

> See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so
> 
>
> Key: SSHD-925
> URL: https://issues.apache.org/jira/browse/SSHD-925
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: scp, security-issue
>
> From [OpenSSH version 8.0 release 
> notes|https://www.openssh.com/txt/release-8.0]
> {quote}
> This release contains mitigation for a weakness in the scp(1) tool and 
> protocol (CVE-2019-6111): when copying files from a remote system to a local 
> directory, scp(1) did not verify that the filenames that the server sent 
> matched those requested by the client. This could allow a hostile server to 
> create or clobber unexpected local files with attacker-controlled content.
> {quote}
> If indeed this vulnerability exists then also note the following
> {quote}
> The scp protocol relies on the remote shell for wildcard expansion, so there 
> is no infallible way for the client's wildcard matching to perfectly reflect 
> the server's. If there is a difference between client and server wildcard 
> expansion, the client may refuse files from the server. For this reason, we 
> have provided a new "-T" flag to scp that disables these client-side checks 
> at the risk of reintroducing the attack described above.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-925:
-

When downloading a single file, it seems that the vulnerability does not exist 
since the client determines the local {{Path}} regardless of the name reported 
reported by the server when data is actually received. In this context, perhaps 
we should add a (configurable) validity check that the name reported by the 
server matches the one requested by the client. Note though that such a check 
is not trivial - e.g., do we check only the file name or the entire relative 
path ?

> See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so
> 
>
> Key: SSHD-925
> URL: https://issues.apache.org/jira/browse/SSHD-925
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: scp, security-issue
>
> From [OpenSSH version 8.0 release 
> notes|https://www.openssh.com/txt/release-8.0]
> {quote}
> This release contains mitigation for a weakness in the scp(1) tool and 
> protocol (CVE-2019-6111): when copying files from a remote system to a local 
> directory, scp(1) did not verify that the filenames that the server sent 
> matched those requested by the client. This could allow a hostile server to 
> create or clobber unexpected local files with attacker-controlled content.
> {quote}
> If indeed this vulnerability exists then also note the following
> {quote}
> The scp protocol relies on the remote shell for wildcard expansion, so there 
> is no infallible way for the client's wildcard matching to perfectly reflect 
> the server's. If there is a difference between client and server wildcard 
> expansion, the client may refuse files from the server. For this reason, we 
> have provided a new "-T" flag to scp that disables these client-side checks 
> at the risk of reintroducing the attack described above.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Work started] (SSHD-924) Add code samples for common flows

[Goldstein Lyor (JIRA)]

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

Work on SSHD-924 started by Goldstein Lyor.
---
> Add code samples for common flows
> -
>
> Key: SSHD-924
> URL: https://issues.apache.org/jira/browse/SSHD-924
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Labels: doc, documentation
>
> * Using {{PropertyResolverUtils}} to configure values
> * Configuring heartbeat parameters - including custom
> * Correctly setting up a shell channel consumer and its threads
> * Simple SFTP/SCP actions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-923.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Avoid infinite waits on incoming data
> -
>
> Key: SSHD-923
> URL: https://issues.apache.org/jira/browse/SSHD-923
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
>
> There are a few locations where the code waits for data buffers to be placed 
> on some "queue" and then signaled that this has been done. For this purpose, 
> it uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can 
> cause waiting threads to hang forever even though the session/channel has 
> been closed.
>  We should
> * Replace these with reasonable *configurable* timeouts.
> * Make sure that the wait is signaled if the relevant session/channel is 
> closed so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SSHD-926) Add support for OpenSSH "lsets...@openssh.com" SFTP protocol extension

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-926:
---

 Summary: Add support for OpenSSH "lsets...@openssh.com" SFTP 
protocol extension
 Key: SSHD-926
 URL: https://issues.apache.org/jira/browse/SSHD-926
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Goldstein Lyor


Replicates the functionality of the existing SSH2_FXP_SETSTAT operation but 
does not follow symlinks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SSHD-925) See if SCP vulnerability CVE-2019-6111 applies and mitigate it if so

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-925:
---

 Summary: See if SCP vulnerability CVE-2019-6111 applies and 
mitigate it if so
 Key: SSHD-925
 URL: https://issues.apache.org/jira/browse/SSHD-925
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor


>From [OpenSSH version 8.0 release 
>notes|https://www.openssh.com/txt/release-8.0]
{quote}
This release contains mitigation for a weakness in the scp(1) tool and protocol 
(CVE-2019-6111): when copying files from a remote system to a local directory, 
scp(1) did not verify that the filenames that the server sent matched those 
requested by the client. This could allow a hostile server to create or clobber 
unexpected local files with attacker-controlled content.
{quote}

If indeed this vulnerability exists then also note the following
{quote}
The scp protocol relies on the remote shell for wildcard expansion, so there is 
no infallible way for the client's wildcard matching to perfectly reflect the 
server's. If there is a difference between client and server wildcard 
expansion, the client may refuse files from the server. For this reason, we 
have provided a new "-T" flag to scp that disables these client-side checks at 
the risk of reintroducing the attack described above.
{quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-923:
-

Good - I will merge it in some time soon and it will be part of the next 
release (2.3.0) which I hope will this month or next

> Avoid infinite waits on incoming data
> -
>
> Key: SSHD-923
> URL: https://issues.apache.org/jira/browse/SSHD-923
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> There are a few locations where the code waits for data buffers to be placed 
> on some "queue" and then signaled that this has been done. For this purpose, 
> it uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can 
> cause waiting threads to hang forever even though the session/channel has 
> been closed.
>  We should
> * Replace these with reasonable *configurable* timeouts.
> * Make sure that the wait is signaled if the relevant session/channel is 
> closed so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-923:
-

[~smoking] Please try https://github.com/lgoldstein/mina-sshd/tree/SSHD-923 and 
see if it releases the NIO2 thread (eventually).
Please review the code in 
{{org.apache.sshd.agent.local.AgentForwardedChannel#request}} and see if you 
can think of any improvements

> Avoid infinite waits on incoming data
> -
>
> Key: SSHD-923
> URL: https://issues.apache.org/jira/browse/SSHD-923
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> There are a few locations where the code waits for data buffers to be placed 
> on some "queue" and then signaled that this has been done. For this purpose, 
> it uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can 
> cause waiting threads to hang forever even though the session/channel has 
> been closed.
>  We should
> * Replace these with reasonable *configurable* timeouts.
> * Make sure that the wait is signaled if the relevant session/channel is 
> closed so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-921.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

Closing this issue - let's continue discussion on SSHD-923

> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Work started] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

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

Work on SSHD-923 started by Goldstein Lyor.
---
> Avoid infinite waits on incoming data
> -
>
> Key: SSHD-923
> URL: https://issues.apache.org/jira/browse/SSHD-923
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> There are a few locations where the code waits for data buffers to be placed 
> on some "queue" and then signaled that this has been done. For this purpose, 
> it uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can 
> cause waiting threads to hang forever even though the session/channel has 
> been closed.
>  We should
> * Replace these with reasonable *configurable* timeouts.
> * Make sure that the wait is signaled if the relevant session/channel is 
> closed so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SSHD-924) Add code samples for common flows

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-924:
---

 Summary: Add code samples for common flows
 Key: SSHD-924
 URL: https://issues.apache.org/jira/browse/SSHD-924
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor


* Using {{PropertyResolverUtils}} to configure values
* Configuring heartbeat parameters - including custom
* Correctly setting up a shell channel consumer and its threads
* Simple SFTP/SCP actions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-921 at 6/16/19 1:31 PM:
--

I see the change - however I am not sure why {{authTimeout}} is the correct one 
to wait ? What if there is no traffic on the channel ? Perhaps the session 
IDLE_TIMEOUT would be better suited here - or maybe an entirely *new* 
configuration value (in which case - what should be its default value...?)
 
See SSHD-923 that I created for this purpose


was (Author: lgoldstein):
I see the change - however I am not sure why {{authTimeout}} is the correct one 
to wait ? What if there is no traffic on the channel ? Perhaps the session 
IDLE_TIMEOUT would be better suited here - or maybe an entirely *new* 
configuration value (in which case - what should be its default value...?)

> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-923:
-

Candidate locations:

* {{DefaultSftpClient#receive}}
* {{(local) AgentForwardedChannel#request}}
* {{(Unix) AgentClient#request}}

> Avoid infinite waits on incoming data
> -
>
> Key: SSHD-923
> URL: https://issues.apache.org/jira/browse/SSHD-923
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> There are a few locations where the code waits for data buffers to be placed 
> on some "queue" and then signaled that this has been done. For this purpose, 
> it uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can 
> cause waiting threads to hang forever even though the session/channel has 
> been closed.
>  We should
> * Replace these with reasonable *configurable* timeouts.
> * Make sure that the wait is signaled if the relevant session/channel is 
> closed so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SSHD-923) Avoid infinite waits on incoming data

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-923:
---

 Summary: Avoid infinite waits on incoming data
 Key: SSHD-923
 URL: https://issues.apache.org/jira/browse/SSHD-923
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor


There are a few locations where the code waits for data buffers to be placed on 
some "queue" and then signaled that this has been done. For this purpose, it 
uses an "infinite" _wait()_ call on  a {{synchronized}} object. This can cause 
waiting threads to hang forever even though the session/channel has been closed.

 We should
* Replace these with reasonable *configurable* timeouts.
* Make sure that the wait is signaled if the relevant session/channel is closed 
so it will detect the closed stream faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-921:
-

I see the change - however I am not sure why {{authTimeout}} is the correct one 
to wait ? What if there is no traffic on the channel ? Perhaps the session 
IDLE_TIMEOUT would be better suited here - or maybe an entirely *new* 
configuration value (in which case - what should be its default value...?)

> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-862) Provide session context to FilePasswordProvider

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-862:
-

{quote}
it seems to be a valid use case to pass in null?
{quote}
Yes, although the code tries to provide the session instance whenever possible 
- i.e., if invoked during a session setup it will definitely not be null. 
However, in some cases (as described in the  documentation) there might not be 
any session available - e.g., when attempting to decrypt a password protected 
file off-line. The documentation simply indicates that if you are implementing 
a {{FilePasswordProvider}} then you must take into account possible _null_ as 
the session context.

{quote}
Just wonder if it can be done better and pass session context instance
{quote}
How is this different than what is provided currently ? Please note that 
{{Session}}, and therefore {{ClientSession/ServerSession}} are all extensions 
of the {{SessionContext}}. In other words, when not null it is likely to be one 
or the other.

> Provide session context to FilePasswordProvider
> ---
>
> Key: SSHD-862
> URL: https://issues.apache.org/jira/browse/SSHD-862
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.1.1
>
>
> Provide the session context (if known) to the {{FilePasswordProvider}} - 
> e.g., decide on different behavior based on the session attributes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Work started] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Work on SSHD-921 started by Goldstein Lyor.
---
> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-921:
-

I have not been able to figure out what is causing the behavior you describe, 
however I have made some changes to improve handling of disconnects in general 
and due to timeouts in particular. Please try 
https://github.com/lgoldstein/mina-sshd/tree/SSHD-921 and let me know if it 
helps in any way - if it does not fix the problem does it alleviate it ?

> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-921:
-

I am not sure that the "trick" you played on the code really helps simulate the 
problem since it may introduce a synthetic error:

The code detects an authentication timeout and attempts to send an 
{{SSH_MSG_DISCONNECT}} message. It attaches a {{Future}} listener to close the 
session once message is sent. However, the message is never sent because of the 
{{writeData}} change. It is however appended to the receive buffer.

This occurs every 1-2 seconds since the session is still "active" as far as the 
thread that checks the timeouts is concerned - so it attempts to send another 
{{SSH_MSG_DISCONNECT}} (and another, and another) - as the log clearly 
seems to indicate. These messages keep accumulating in the receive buffer, but 
no one is sending them. Also, the peer does not know that the session is closed 
so it does not disconnect - so OOM is likely.

That being said, I will keep looking at the code since the scenario I just 
described might not explain 100% the behavior you experienced - there are a few 
points of interest that I need to research further.


> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SSHD-921) OutOfMemory Error in extreme situations

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-921:
---

Assignee: Goldstein Lyor

> OutOfMemory Error in extreme situations
> ---
>
> Key: SSHD-921
> URL: https://issues.apache.org/jira/browse/SSHD-921
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.7.0, 2.0.0
>Reporter: Zhenliang Su
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: Main.java, jstack.txt
>
>
> The demo code run in my local machine.
>  When I 'ssh root@127.0.0.1 -p 2233', my demo will use the agent forwarding 
> feature to login 10.10.16.201.
>  In most cases, it's ok. But in few cases, for example, client disconnect 
> suddenly, it will lead to OutOfMemory Error.
>  To simulate this scenario of OutOfMemory Error, I did some trick to the sshd 
> code:
>  1. In org.apache.sshd.common.future.DefaultSshFuture#setValue:
> {code:java}
> public void setValue(Object newValue) {
>   // to simulate race condition
>   try {
>   Thread.sleep(10);
>   } catch (Exception e) {
>   // ignore
>   }
> synchronized (lock) {
> // Allow only once.
> if (result != null) {
> return;
> }
> result = (newValue != null) ? newValue : GenericUtils.NULL;
> lock.notifyAll();
> }
> notifyListeners();
> }
> {code}
> 2. In org.apache.sshd.agent.local.AgentForwardedChannel#doWriteData:
> {code:java}
>  protected void doWriteData(byte[] data, int off, long len) throws 
> IOException {
> ValidateUtils.checkTrue(len <= Integer.MAX_VALUE, "Data length 
> exceeds int boundaries: %d", len);
> Buffer message = null;
> synchronized (receiveBuffer) {
> receiveBuffer.putBuffer(new ByteArrayBuffer(data, off, (int) 
> len));
> // to simulate client disconnect suddenly
> if (false && receiveBuffer.available() >= 4) {
> off = receiveBuffer.rpos();
> len = receiveBuffer.getInt();
> receiveBuffer.rpos(off);
> if (receiveBuffer.available() >= (4 + len)) {
> message = new ByteArrayBuffer(receiveBuffer.getBytes());
> receiveBuffer.compact();
> }
> }
> }
> if (message != null) {
> synchronized (messages) {
> messages.offer(message);
> messages.notifyAll();
> }
> }
> }
> {code}
> After two munites, my console displayed 
> '[sshd-SshClient[720b3c53]-timer-thread-1] INFO 
> org.apache.sshd.client.session.ClientSessionImpl - 
> Disconnecting(ClientSessionImpl[root@/10.10.16.201:8022]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Session has timed out waiting for 
> authentication after 12 ms.' every second, and finally lead to 
> OutOfMemory Error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SSHD-922) CD - change directory is not working. clientSession.executeRemoteCommand("cd " + directory)

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-922.
-
Resolution: Not A Problem
  Assignee: Goldstein Lyor

The code seems to indicate some confusion as to what a remote command is. 
{{executeRemoteCommand}} uses an "exec" channel. Such a channel is used to run 
a *single* command and then disconnect. When the channel is established by the 
server, some "home" directory is assigned by the *server*. The "cd" command 
succeeds but then the channel is closed and the server forgets all about it. 
When "pwd" command is issued, it will show the default home directory - same 
one from which "cd" was executed. In other words, an "exec" command is 
"stateless" inasmuch as the server will forget any CWD, TTY settings, etc...

If you wish to maintain the "state" then you must use a "shell" channel - and 
even then the state (e.g. CWD) will be maintained only for the duration of the 
shell session/channel. Once it is closed, the server will revert back to its 
default settings (until the next shell/command).

> CD - change directory is not working. clientSession.executeRemoteCommand("cd 
> " + directory)
> ---
>
> Key: SSHD-922
> URL: https://issues.apache.org/jira/browse/SSHD-922
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Trying to connect to a Linux VM from Windows OS
>Reporter: Zabee Ulla
>Assignee: Goldstein Lyor
>Priority: Blocker
>
> I am writing an SSHD client to execute BASH commands on a remove Linux VM. My 
> functionality requires to change directories at several points. 
> I have written and using below code and not finding change directory working. 
> I tried a few other Linux commands and am able to execute them perfectly 
> except change directory. 
> This is a blocker for me to embed and implement Apache SSHD client for my 
> application. 
> Please note that "pwd" output is same before and after 
> _+*session.executeRemoteCommand("cd " + argDirectory);*+_'s execution.
> /**
>  * An implementation of an SFTP client that uses the Apache Mina library.
>  */
>  public class MinaSftp {
> _public void changeRemoteDirectory(String argDirectory)_
>  _throws IOException {_
>  _try {_
>  _System.out.println("Present working direcotry :\n " + 
> _session.executeRemoteCommand("pwd"));_
> _+*String output = _session.executeRemoteCommand("cd " + argDirectory);*+_
> _System.out.println("Present working direcotry :\n " + 
> _session.executeRemoteCommand("pwd"));_
>  _System.out.println("Change directory output: " + output);_
>  _}_
>  _catch (IOException ex) {_
>  _handleException(ex, action);_
>  _}_
>  _}_
> private static Collection ccEvents = 
> Arrays.asList(ClientChannelEvent.CLOSED);
> private String _username = "userName";
>  private String _password = "password";
>  private String _host = "aValidHostName";
>  private ClientSession _session;
>  private ClientChannel _channel;
>  private SshClient _client;
> // Some valid port number
>  private int portNumber = 8999;
>  
> public void connect()
>  throws IOException {
> _client = SshClient.setUpDefaultClient();
>  _client.start();
> ConnectFuture connectFuture = _client.connect(_username, _host, portNumber);
>  connectFuture.await();
>  _session = connectFuture.getSession();
>  _channel = _session.createChannel(ClientChannel.CHANNEL_SHELL);
>  _session.addPasswordIdentity(_password);
> // TODO : fix timeout
>  _session.auth().verify(Integer.MAX_VALUE);
> if (_session.isAuthenticated())
> { System.out.println("Authentication successful"); }
> else
> { System.out.println("Authentication failed"); }
> _channel.waitFor(ccEvents, 200);
>  }
> public void disconnect() {
>  LOG.debug("Disconnecting from the SFTP host.");
> // Disconnecting the session disconnects all of the connected channels as 
> well.
>  if (_channel != null) {
>  try
> { _channel.close(); }
> catch (Exception e)
> { // Do nothing. This is okay. }
> }
>  if (_session != null)
> { _session.close(false); }
> if (_client != null)
> { _client.stop(); }
> }
> private void handleException(Exception argEx, String argAction)
>  throws IOException
> { throw LOG.throwing(new IOException(argAction + " on the SFTP host threw an 
> exception.", argEx)); }
> }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-902.
-
   Resolution: Fixed
Fix Version/s: 2.0.3

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Assignee: Goldstein Lyor
>Priority: Critical
> Fix For: 2.0.3
>
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-902:
---

Assignee: Goldstein Lyor

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Assignee: Goldstein Lyor
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Work on SSHD-902 started by Goldstein Lyor.
---
> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Assignee: Goldstein Lyor
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-916.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-916:
-

Great - will do so in the next few days - thanks for validating the code

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-916:
-

No hurry - you can even take a few days longer - I just wanted to make sure we 
do not let it fall between the cracks

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-916:
-

Hi [~roberto.deandrea] - any progress on evaluating this fix ? I would like to 
merge it in and perhaps release a new version some time during June...

Thx.

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-920) Scp Subsystem does not support java.nio.file.FileSystem

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-920.
-
   Resolution: Implemented
 Assignee: Goldstein Lyor
Fix Version/s: 2.3.0

Please try the latest (snapshot) version - fixed by SSHD-893

> Scp Subsystem does not support java.nio.file.FileSystem
> ---
>
> Key: SSHD-920
> URL: https://issues.apache.org/jira/browse/SSHD-920
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Fulvio Cavarretta
>Assignee: Goldstein Lyor
>Priority: Blocker
> Fix For: 2.3.0
>
>
> If you plug a custom java.nio.file.FileSystem into Apache SSHD, some scp use 
> case are not supported.
> Specifically if you download from apache-sshd using wildcard like:
> scp user1@apache-sshd:/home/user1/* /tmp
> Command does not succed.
> This because in 
> *ScpFileOpener.getMatchingFilesToSend*
> the class *DirectoryScanner*, used to retrieve list of files to be 
> transferred, does not relies on java.nio.file.FileSystem plugged into SSHD, 
> but just leverage on local file system.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-919) sshd suport ssh v1 or not

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-919:
-

As far as I know Apache SSHD is compatible with SSH v1, however its defaults 
are geared towards v2. I admit I have never looked  into the possibility of 
setting it up for v1 compatibility since v2 is the de-facto prevailing 
standard. There is nothing a-priori that comes to mind to preclude such a 
setup, although I suspect support for old/obsolete KEX, ciphers, signatures is 
lacking.

> sshd suport ssh v1 or not
> -
>
> Key: SSHD-919
> URL: https://issues.apache.org/jira/browse/SSHD-919
> Project: MINA SSHD
>  Issue Type: Question
>Reporter: tk0214
>Priority: Major
>  Labels: features
>
> from the code, we find the sshd sopport  SSH-1.99, but failed to to ssh v1 
> server in testw 
> the ssh server used sshd, the protocol set 1
> i want to know sshd-2.0.0 version support SSH v1 or not.
> thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-917) Add support for SSH2 public key file format

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-917.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Add support for SSH2 public key file format
> ---
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.3.0
>
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SSHD-918) Implement UMAC message authentication code

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor updated SSHD-918:

Description: 
https://tools.ietf.org/html/draft-miller-secsh-umac-01
https://tools.ietf.org/html/rfc4418

  was:https://tools.ietf.org/html/draft-miller-secsh-umac-01


> Implement UMAC message authentication code
> --
>
> Key: SSHD-918
> URL: https://issues.apache.org/jira/browse/SSHD-918
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Priority: Minor
>
> https://tools.ietf.org/html/draft-miller-secsh-umac-01
> https://tools.ietf.org/html/rfc4418



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SSHD-917) Add support for SSH2 public key file format

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor updated SSHD-917:

Summary: Add support for SSH2 public key file format  (was: Add support for 
SSH2 public/private key files)

> Add support for SSH2 public key file format
> ---
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SSHD-917) Add support for SSH2 public/private key files

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-917:
---

Assignee: Goldstein Lyor

> Add support for SSH2 public/private key files
> -
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-917) Add support for SSH2 public/private key files

[Goldstein Lyor (JIRA)]

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

Work on SSHD-917 started by Goldstein Lyor.
---
> Add support for SSH2 public/private key files
> -
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Minor
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-917) Add support for SSH2 public/private key files

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-917:
-

{code:bash|title=Convert existing key file to SSH2 format}
ssh-keygen -e -f ...path/to/file...
{code}

> Add support for SSH2 public/private key files
> -
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Priority: Minor
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SSHD-917) Add support for SSH2 public/private key files

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor updated SSHD-917:

Summary: Add support for SSH2 public/private key files  (was: Add support 
for SSH2 public/private key fiels)

> Add support for SSH2 public/private key files
> -
>
> Key: SSHD-917
> URL: https://issues.apache.org/jira/browse/SSHD-917
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Goldstein Lyor
>Priority: Minor
>
> [https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-918) Implement UMAC message authentication code

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-918:
---

 Summary: Implement UMAC message authentication code
 Key: SSHD-918
 URL: https://issues.apache.org/jira/browse/SSHD-918
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.3.0
Reporter: Goldstein Lyor


https://tools.ietf.org/html/draft-miller-secsh-umac-01



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-916:
-

Please try https://github.com/lgoldstein/mina-sshd/tree/SSHD-916 and let me 
know.

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-917) Add support for SSH2 public/private key fiels

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-917:
---

 Summary: Add support for SSH2 public/private key fiels
 Key: SSHD-917
 URL: https://issues.apache.org/jira/browse/SSHD-917
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.3.0
Reporter: Goldstein Lyor


[https://tools.ietf.org/html/rfc4716]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-916:
---

Assignee: Goldstein Lyor

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Work on SSHD-916 started by Goldstein Lyor.
---
> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-916) Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-916:
-

Thanks - will look  at it when I get a chance..

> Followup of SSHD-912 Review usages of AbstractCloseable#lock and constrain 
> them only to actually needed ones
> 
>
> Key: SSHD-916
> URL: https://issues.apache.org/jira/browse/SSHD-916
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>
> Hi Lyor,
> Yesterday I said you that no deadlock occurred with the new code changes, but 
> I spoke too early :(
> I found a third thread deadlock on SSH client running our long run test 
> always during client/server disconnection.
>  
> The deadlock is as follows :
> Thread #22175 name: sshd-SshClient[ad946082]-nio2-thread-2
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:873)
>  WAITFOR(encodedLock)
> 
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:362)
>  LOCKED(sessionLock)
>  
> Thread #22180 name: sshd-SshClient[ad946082]-nio2-thread-7
> — 
> org.apache.sshd.client.session.ClientSessionImpl.signalAuthFailure(ClientSessionImpl.java:151)
>   WAITFOR(sessionLock)
> .
> — 
> org.apache.sshd.common.session.helpers.AbstractSession.doWritePacket(AbstractSession.java:876)
>  LOCKED(encodedLock)
>  
> Attached you can find a full thread dump regarding the new deadlock. (see 
> file spxp.usrdump.9503...@aix72.dmz.20190510114505768.log)
> Let me know if you prefer open a new ticket and troubleshoot this issue.
>  
> Kind Regards
> Roberto Deandrea



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-912:
-

Please open a new ticket on  it

> Review usages of AbstractCloseable#lock and constrain them only to actually 
> needed ones
> ---
>
> Key: SSHD-912
> URL: https://issues.apache.org/jira/browse/SSHD-912
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: spxp.usrdump.9503...@aix72.dmz.20190510114505768.log
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
> stuff not related to them. We should take a look at it and separate these 
> uses so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas 
> all other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-912.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Review usages of AbstractCloseable#lock and constrain them only to actually 
> needed ones
> ---
>
> Key: SSHD-912
> URL: https://issues.apache.org/jira/browse/SSHD-912
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
> stuff not related to them. We should take a look at it and separate these 
> uses so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas 
> all other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-912:
-

{quote}Do you plan to incorporate these code changes in Apache SSHD 2.3.0 
release ?{quote}
Indeed I do -  I believe we will release it some time in June or July...

> Review usages of AbstractCloseable#lock and constrain them only to actually 
> needed ones
> ---
>
> Key: SSHD-912
> URL: https://issues.apache.org/jira/browse/SSHD-912
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
> stuff not related to them. We should take a look at it and separate these 
> uses so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas 
> all other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-915) Add support for RSA key exchange methods (RFC 4432)

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-915:
---

 Summary: Add support for RSA key exchange methods (RFC 4432)
 Key: SSHD-915
 URL: https://issues.apache.org/jira/browse/SSHD-915
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.3.0
Reporter: Goldstein Lyor


[https://tools.ietf.org/html/rfc4432]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-914) Add Python script using Paramiko to connect to MINA SSHD for testing

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-914:
---

 Summary: Add Python script using Paramiko to connect to MINA SSHD 
for testing
 Key: SSHD-914
 URL: https://issues.apache.org/jira/browse/SSHD-914
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.3.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor


h5. Goals

* Use [Paramiko client|http://docs.paramiko.org/en/2.4/api/client.html] code to 
create a "sanity" script to "exercise" the SSHD server in order to verify 
compatibility (and perhaps glean new feature).
* Consider adding a {{Python}} sanity test as part of the regular unit tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-913) Provide session instance to command and/or shell factories creators

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-913.
-
   Resolution: Fixed
Fix Version/s: (was: 2.2.0)
   2.3.0

> Provide session instance to command and/or shell factories creators
> ---
>
> Key: SSHD-913
> URL: https://issues.apache.org/jira/browse/SSHD-913
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
>
> The session/channel through which the command is being created is not 
> propagated to either the command or shell factory. This information may be 
> very useful for (e,g,) restricting access to such services based on 
> authenticated user.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-913) Provide session instance to command and/or shell factories creators

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-913:
---

 Summary: Provide session instance to command and/or shell 
factories creators
 Key: SSHD-913
 URL: https://issues.apache.org/jira/browse/SSHD-913
 Project: MINA SSHD
  Issue Type: Improvement
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor
 Fix For: 2.2.0


The session/channel through which the command is being created is not 
propagated to either the command or shell factory. This information may be very 
useful for (e,g,) restricting access to such services based on authenticated 
user.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-913) Provide session instance to command and/or shell factories creators

[Goldstein Lyor (JIRA)]

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

Work on SSHD-913 started by Goldstein Lyor.
---
> Provide session instance to command and/or shell factories creators
> ---
>
> Key: SSHD-913
> URL: https://issues.apache.org/jira/browse/SSHD-913
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.2.0
>
>
> The session/channel through which the command is being created is not 
> propagated to either the command or shell factory. This information may be 
> very useful for (e,g,) restricting access to such services based on 
> authenticated user.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-912:
-

[~roberto.deandrea] I have made some changes - please clone 
https://github.com/lgoldstein/mina-sshd/tree/SSHD-912 and see if it solves the 
deadlock. You can also review the changes in the associated PR - 
https://github.com/apache/mina-sshd/pull/102

I am still reviewing the code since it is a change in something very basic so I 
want to be sure we have not missed anything.

> Review usages of AbstractCloseable#lock and constrain them only to actually 
> needed ones
> ---
>
> Key: SSHD-912
> URL: https://issues.apache.org/jira/browse/SSHD-912
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
> stuff not related to them. We should take a look at it and separate these 
> uses so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas 
> all other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-911.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

[~roberto.deandrea] Marking this issue as fixed - let's continue the discussion 
regarding the 2nd deadlock in SSHD-912 which I have opened specifically for it.

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log, 
> spxp.usrdump.33095...@aix72.dmz.20190423123751496.log
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

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

Work on SSHD-912 started by Goldstein Lyor.
---
> Review usages of AbstractCloseable#lock and constrain them only to actually 
> needed ones
> ---
>
> Key: SSHD-912
> URL: https://issues.apache.org/jira/browse/SSHD-912
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 2.2.0
>Reporter: Goldstein Lyor
>Assignee: Goldstein Lyor
>Priority: Major
>
> The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
> stuff not related to them. We should take a look at it and separate these 
> uses so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas 
> all other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-911:
-

I am a bit confused - in the new deadlock you report it seems to revolve only 
around the {{encodeLock}} so I don't see how a deadlock can occur. On the other 
hand, you mention {{AbstractCloseable#lock}} as the participant in the 
deadlock. I am therefore not sure who is locking what and why is it causing a 
deadlock.

Nevertheless, I took a closer look at the  {{AbstractCloseable#lock}} and it 
seems that code rather "abuses" it. However, figuring out where is it really 
needed and where it isn't is quite an upheaval, so I have opened a *separate* 
issue for it (SSHD-912). 

That being said, the only way I can figure out a deadlock between the  
{{encodeLock}} and the {{AbstractCloseable#lock}}  is if thread A somehow lock 
{{AbstractCloseable#lock}} and tries to write a packet (which seems a possible 
scenario) while thread B tries to lock {{AbstractCloseable#lock}} while already 
holding {{encodeLock}} - which my current code analysis does not seem to 
indicate is possible (but I'll keep looking).

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log, 
> spxp.usrdump.33095...@aix72.dmz.20190423123751496.log
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SSHD-912) Review usages of AbstractCloseable#lock and constrain them only to actually needed ones

[Goldstein Lyor (JIRA)]

Goldstein Lyor created SSHD-912:
---

 Summary: Review usages of AbstractCloseable#lock and constrain 
them only to actually needed ones
 Key: SSHD-912
 URL: https://issues.apache.org/jira/browse/SSHD-912
 Project: MINA SSHD
  Issue Type: Improvement
Affects Versions: 2.2.0
Reporter: Goldstein Lyor
Assignee: Goldstein Lyor


The  {{AbstractCloseable#lock}} is used in various {{Future}}-s but also for 
stuff not related to them. We should take a look at it and separate these uses 
so that {{AbstractCloseable#lock}} is used only for {{Future}}-s whereas all 
other code uses a *separate* lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-902 at 4/30/19 4:12 AM:
--

I have not had any feedback on the PR I published - especially whether it fixes 
the problem - so I don't know whether to merge it in or not - please review, 
test and approve (or not...).


was (Author: lgoldstein):
I have not had any feedback on the PR I published - especially whether it fixes 
the problem - so I don't know whether to merge it in or not - please review, 
test and approve (or not...)/

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-902:
-

I have not had any feedback on the PR I published - especially whether it fixes 
the problem - so I don't know whether to merge it in or not - please review, 
test and approve (or not...)/

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-911:
-

{quote}
With your suggested code changes the old deadlock seems definetely FIXED
{quote}
I am not so sure -  it feels like all it does is minimize the chance of a 
deadlock by changing the timing so your test suite probable isn't fast enough 
or does not "score" the correct timing. I am not sure that the root cause (if 
indeed there is a deadlock) has been fixed. Furthermore, seems like a bit of an 
overhead to check if channel/session are open for each and every packet. Will 
reflect on this some more...

{quote}
Can you please help me to fix this new deadlock ?
{quote}
I'll see what I can do.


> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log, 
> spxp.usrdump.33095...@aix72.dmz.20190423123751496.log
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-911:
-

I have looked in the specified code area and its use, but have not found 
anything suspicious. AFAIK there are no _lock-wait-until_ loops and the order 
of the acquired locks seems consistent.

I have [made a change|https://github.com/apache/mina-sshd/pull/101] that while 
does not explain the deadlock, perhaps mitigates it. Try cloning 
[https://github.com/lgoldstein/mina-sshd/tree/SSHD-911] and using it to see if 
it fixes or at least mitigates the issue - let me know.

 Specifically, the {{ClientChannelPendingMessagesQueue}} is involved only in 
port forwarding code, so it would seem that not only {quote}a quite large 
number of client data connections (i.e 20/30 connections) are flowing to target 
servers.{quote} but some of them are involved in port forwarding. Perhaps we 
can somehow isolate them and figure out what they are doing that may cause a 
deadlock (assuming it always deadlock at the same location).

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-911:
-

Thanks, will look at it...

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log
>
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-911:
-

{quote}Can you please troubleshoot this problem ?{quote}
I'll see what I can do - it will take some time though... 

In any case, any additional information you can provide may prove helpful - 
e.g. can you try and focus some more when the "sometimes" occurs ? Is it often 
or rare ? Perhaps you can open some *selective* debug log levels and see what 
happens around the time that it seems to hang.

{quote}
The deadlock is regarding the ClientChannelPendingMessagesQueue class added to 
fix routing problems for local port forwarding in the past.
{quote}
Can you explain what leads you to believe that this class code is causing the 
problem ?

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log
>
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SSHD-911) Deadlock in Apache SshClient used for local port forwarding

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-911:
---

Assignee: Goldstein Lyor

> Deadlock in Apache SshClient used for local port forwarding
> ---
>
> Key: SSHD-911
> URL: https://issues.apache.org/jira/browse/SSHD-911
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Roberto Deandrea
>Assignee: Goldstein Lyor
>Priority: Major
> Attachments: spxp.usrdump.20382...@aix72.dmz.20190417205240026.log
>
>
> Hi Lyor,
> We have an Apache SSHD 2.2.0 client and server SSH pair used for local port 
> forwarding of different protocols.
> In our lab environment we found that sometimes when the SSH client for any 
> reason is disconnecting from the SSH server, a DEADLOCK happens on the 
> sshClient regarding the threads in the thread pool.
> We are using builtin nio2 implementation for our SshClient.
> The deadlock is regarding the ClientChannelPendingMessagesQueue class added 
> to fix routing problems for local port forwarding in the past.
> Attached you can find the thread dump taken after the deadlock happend.
>  
> Can you please troubleshoot this problem ?
> [^spxp.usrdump.20382...@aix72.dmz.20190417205240026.log]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-908) Leak of process handles caused by local port forwarding connections

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-908.
---
Resolution: Not A Problem

> Leak of process handles caused by local port forwarding connections
> ---
>
> Key: SSHD-908
> URL: https://issues.apache.org/jira/browse/SSHD-908
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: repro.zip
>
>
> Hi,
> We have build an Apache SSHD Client (based on Apache SSHD 2.1.0) to forward 
> local sockets to target servers.
> Our client is configured to use NIO2 builtin service provider, NIO2 Mina 
> service provider and NIO2 Netty service provider.
> We have detected a leak of handles monitoring the java process with ALL above 
> NIO2 service provider.
> When the limit of handles per process is reached, the java process become 
> unresponsive.
>  
> We suspect that the problem could be into Apache SSHD Client code.
> The problem is reproducible in our lab environment.
>  
> Can you help us troubleshoot this problem and in that case what kind of info 
> you need ?
> Did you see a similar problem before and if so, can you give us a solution ?
>  
> Kind Regards
> Roberto Deandrea
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-902 at 4/17/19 4:46 PM:
--

See comment on the PR... + opened [updated 
PR|https://github.com/apache/mina-sshd/pull/100]


was (Author: lgoldstein):
See comment on the PR... + opened [updated 
PR|https://github.com/apache/mina-sshd/pull/|https://github.com/apache/mina-sshd/pulls/100]

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-902 at 4/17/19 4:45 PM:
--

See comment on the PR... + opened [updated 
PR|https://github.com/apache/mina-sshd/pull/|https://github.com/apache/mina-sshd/pulls/100]


was (Author: lgoldstein):
See comment on the PR... + opened [updated 
PR|https://github.com/apache/mina-sshd/pull/|https://github.com/apache/mina-sshd/pull/100]

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-902 at 4/16/19 7:58 AM:
--

See comment on the PR... + opened [updated 
PR|https://github.com/apache/mina-sshd/pull/|https://github.com/apache/mina-sshd/pull/100]


was (Author: lgoldstein):
See comment on the PR...

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor edited comment on SSHD-902 at 4/16/19 7:57 AM:
--

Pull request is created as  [Shutdown output when receiving SSH_MSG_CHANNEL_EOF 
message|https://github.com/apache/mina-sshd/pull/99]. Thanks.


was (Author: ysang):
Pull request is created as  "Shutdown output when receiving SSH_MSG_CHANNEL_EOF 
message.". Thanks.

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-902:
-

See comment on the PR...

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-902:
-

I am having some trouble evaluating the fix you attached since it involves 
several files - can you clone the Github project and create a pull-request with 
your proposed fixed ? Thanks

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-902) Local port forwarding: EOF is not handled properly

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-902:
-

I'll take a look at the fix soon - thanks for it.

> Local port forwarding: EOF is not handled properly
> --
>
> Key: SSHD-902
> URL: https://issues.apache.org/jira/browse/SSHD-902
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
> Environment: OS: both Windows 10 and Red Hat Enterprise Linux Server 
> release 7.4 (Maipo) Linux 4.1.12-124.19.2.el7uek.x86_64 x86_64
> JDK: 1.8.0_201
> SSHD: 2.1.0
>Reporter: Yumin Sang
>Priority: Critical
> Attachments: AbstractServerCloseTestSupport.java, 
> ApacheServerApacheClientTest.java, fixBasedOn2.1.0.zip, packets.PNG
>
>
> Set remote port to a real listening port but is not for DB connection. Start 
> a local port forwarding. Try getting a connection through the established SSH 
> tunnel. This operation is expected to be finished with some error, but it 
> hangs.
> Reproduce steps:
>  # prepare a Linux server and find a listening port, such as 2049, which is 
> not of DB listener.
>  # get attached demo code: ApacheServerApacheClientTest.java and 
> AbstractServerCloseTestSupport.java. They are modified from the ones in 
> mina-sshd-2.1.0\sshd-core\src\test\java\org\apache\sshd\common\forward. 
> Please replace the corresponding ones.
>  # download ojdbc8.jar from 
> [https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html?|https://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html]
>  and add it to classpath.
>  # set up a local port forwarding tunnel by Putty or other tools. Set the 
> forwarded local port to 3, remote server/port to the server/port in step 
> 1.
>  # run  ApacheServerApacheClientTest.java. It finishes with error like 
> java.io.IOException: Got minus one from a read call. This is expected 
> behavior.
>  # change 
> org.apache.sshd.common.forward.AbstractServerCloseTestSupport#testLocalPortForwardOneBuffer:
>  uncomment line "int serverPort = startLocalPF();" and comment line "int 
> serverPort = 3;"
>  # change 
> org.apache.sshd.common.forward.ApacheServerApacheClientTest#createClient, set 
> username, host and password to the ones in step 1.
>  # run  ApacheServerApacheClientTest.java again and it hangs.
> By capturing loopback packets, it can be found the interactions are same, but 
> SSHD make different process from what Putty does. In attached snapshot, the 
> "nfs" is of port 2049.
> Did a bit digging up, and it seems that EOF is not handled properly. Here is 
> a call stack:
> handleEof:873, AbstractChannel (org.apache.sshd.common.channel)
> channelEof:498, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> process:357, AbstractConnectionService 
> (org.apache.sshd.common.session.helpers)
> doHandleMessage:626, AbstractSession (org.apache.sshd.common.session.helpers)
> handleMessage:559, AbstractSession (org.apache.sshd.common.session.helpers)
> decode:1542, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:520, AbstractSession (org.apache.sshd.common.session.helpers)
> messageReceived:63, AbstractSessionIoHandler 
> (org.apache.sshd.common.session.helpers)
> handleReadCycleCompletion:339, Nio2Session (org.apache.sshd.common.io.nio2)
> onCompleted:318, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> onCompleted:315, Nio2Session$1 (org.apache.sshd.common.io.nio2)
> lambda$completed$0:38, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> run:-1, 391147216 
> (org.apache.sshd.common.io.nio2.Nio2CompletionHandler$$Lambda$73)
> doPrivileged:-1, AccessController (java.security)
> completed:37, Nio2CompletionHandler (org.apache.sshd.common.io.nio2)
> invokeUnchecked:126, Invoker (sun.nio.ch)
> run:218, Invoker$2 (sun.nio.ch)
> run:112, AsynchronousChannelGroupImpl$1 (sun.nio.ch)
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:748, Thread (java.lang)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-910) JavaDoc example of SshClient not working

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-910.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> JavaDoc example of SshClient not working
> 
>
> Key: SSHD-910
> URL: https://issues.apache.org/jira/browse/SSHD-910
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Udo Walker
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.3.0
>
>
> The given code example in the official Javadoc of the class SshClient is not 
> working: There is a compile error in this line:
>  
> try(ClientSession session = client.connect(login, host, 
> port).await().getSession()) {
> The method await() returns a boolean so that the call getSession() is not 
> correct.
> The offical page is: 
> [https://mina.apache.org/sshd-project/apidocs/org/apache/sshd/client/SshClient.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (SSHD-910) JavaDoc example of SshClient not working

[Goldstein Lyor (JIRA)]

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

Work on SSHD-910 started by Goldstein Lyor.
---
> JavaDoc example of SshClient not working
> 
>
> Key: SSHD-910
> URL: https://issues.apache.org/jira/browse/SSHD-910
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Udo Walker
>Assignee: Goldstein Lyor
>Priority: Minor
>
> The given code example in the official Javadoc of the class SshClient is not 
> working: There is a compile error in this line:
>  
> try(ClientSession session = client.connect(login, host, 
> port).await().getSession()) {
> The method await() returns a boolean so that the call getSession() is not 
> correct.
> The offical page is: 
> [https://mina.apache.org/sshd-project/apidocs/org/apache/sshd/client/SshClient.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (SSHD-910) JavaDoc example of SshClient not working

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor reassigned SSHD-910:
---

Assignee: Goldstein Lyor

> JavaDoc example of SshClient not working
> 
>
> Key: SSHD-910
> URL: https://issues.apache.org/jira/browse/SSHD-910
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Udo Walker
>Assignee: Goldstein Lyor
>Priority: Minor
>
> The given code example in the official Javadoc of the class SshClient is not 
> working: There is a compile error in this line:
>  
> try(ClientSession session = client.connect(login, host, 
> port).await().getSession()) {
> The method await() returns a boolean so that the call getSession() is not 
> correct.
> The offical page is: 
> [https://mina.apache.org/sshd-project/apidocs/org/apache/sshd/client/SshClient.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-910) JavaDoc example of SshClient not working

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-910:
-

Thanks for the issue - will fix the Javadoc - please note though that project's 
[README|https://github.com/apache/mina-sshd/blob/master/README.md] is 
up-to-date - specifically the [setup a client in 5 
minutes|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md] 
section - where you can find a correct code snippet.

Specifically for the issue you raised, all you need to do is replace _await_ 
with _verify_ and the code will work

> JavaDoc example of SshClient not working
> 
>
> Key: SSHD-910
> URL: https://issues.apache.org/jira/browse/SSHD-910
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Udo Walker
>Priority: Minor
>
> The given code example in the official Javadoc of the class SshClient is not 
> working: There is a compile error in this line:
>  
> try(ClientSession session = client.connect(login, host, 
> port).await().getSession()) {
> The method await() returns a boolean so that the call getSession() is not 
> correct.
> The offical page is: 
> [https://mina.apache.org/sshd-project/apidocs/org/apache/sshd/client/SshClient.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SSHD-910) JavaDoc example of SshClient not working

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor updated SSHD-910:

Priority: Minor  (was: Major)

> JavaDoc example of SshClient not working
> 
>
> Key: SSHD-910
> URL: https://issues.apache.org/jira/browse/SSHD-910
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Udo Walker
>Priority: Minor
>
> The given code example in the official Javadoc of the class SshClient is not 
> working: There is a compile error in this line:
>  
> try(ClientSession session = client.connect(login, host, 
> port).await().getSession()) {
> The method await() returns a boolean so that the call getSession() is not 
> correct.
> The offical page is: 
> [https://mina.apache.org/sshd-project/apidocs/org/apache/sshd/client/SshClient.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-908) Leak of process handles caused by local port forwarding connections

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-908:
-

The leak seems obvious to me

- the {{SshClient}} is created-started-stopped at a very high rate. While we 
have invested a lot of effort into trying to allow SshClient/Server(s) to be 
re-created/started I strongly advise against it. A Java application should use 
*one* instance (client or server or one of each) and use it to create as many 
sessions as necessary. Therefore the use-case depicted in code seems a bit 
unnatural.

- the {{sshSession}} is not properly disposed of

- ditto for the port forwarding

I understand this might be just some sample code, but if it is supposed to 
detect leaks, at least it should be written in a manner as similar as possible 
as real code - otherwise we will not be able to distinguish real leaks from 
"synthetic" ones due to improper disposal of resources.

Here is how I would expect a program to look like (example is for client but 
similar applies to server):

{code:java|title=Main application code sample}
SshClient client = ...setup and configure...
client.start();

while (...program is active...) {
try (ClientSession session =  ...connect and auhenticate using the client 
instance) {
 
 session.startPortForwarding();
try {
  use the forwarding until no longer necessary...
  see also PortForwardingTracker that can be used as a 
try-with-resource instead of this code block...
} finally {
   session.stopPortForwarding();
}
} 
}

client.stop();
{code}

> Leak of process handles caused by local port forwarding connections
> ---
>
> Key: SSHD-908
> URL: https://issues.apache.org/jira/browse/SSHD-908
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: repro.zip
>
>
> Hi,
> We have build an Apache SSHD Client (based on Apache SSHD 2.1.0) to forward 
> local sockets to target servers.
> Our client is configured to use NIO2 builtin service provider, NIO2 Mina 
> service provider and NIO2 Netty service provider.
> We have detected a leak of handles monitoring the java process with ALL above 
> NIO2 service provider.
> When the limit of handles per process is reached, the java process become 
> unresponsive.
>  
> We suspect that the problem could be into Apache SSHD Client code.
> The problem is reproducible in our lab environment.
>  
> Can you help us troubleshoot this problem and in that case what kind of info 
> you need ?
> Did you see a similar problem before and if so, can you give us a solution ?
>  
> Kind Regards
> Roberto Deandrea
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-908) Leak of process handles caused by local port forwarding connections

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-908:
-

Just a quick look at the project raises some questions:

* Why is mina-core 2.1.0 in there ? We do not support it...
* Why are the netty JAR(s) in there ?

Let's remove them and their sshd-mina/netty JAR(s) from the classpath to make 
sure there is no "noise" from them and thus focus on NIO2.

> Leak of process handles caused by local port forwarding connections
> ---
>
> Key: SSHD-908
> URL: https://issues.apache.org/jira/browse/SSHD-908
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: repro.zip
>
>
> Hi,
> We have build an Apache SSHD Client (based on Apache SSHD 2.1.0) to forward 
> local sockets to target servers.
> Our client is configured to use NIO2 builtin service provider, NIO2 Mina 
> service provider and NIO2 Netty service provider.
> We have detected a leak of handles monitoring the java process with ALL above 
> NIO2 service provider.
> When the limit of handles per process is reached, the java process become 
> unresponsive.
>  
> We suspect that the problem could be into Apache SSHD Client code.
> The problem is reproducible in our lab environment.
>  
> Can you help us troubleshoot this problem and in that case what kind of info 
> you need ?
> Did you see a similar problem before and if so, can you give us a solution ?
>  
> Kind Regards
> Roberto Deandrea
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-908) Leak of process handles caused by local port forwarding connections

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-908:
-

Thanks, I'll see when I can find some time to review this issue and try to 
figure out something.

> Leak of process handles caused by local port forwarding connections
> ---
>
> Key: SSHD-908
> URL: https://issues.apache.org/jira/browse/SSHD-908
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: repro.zip
>
>
> Hi,
> We have build an Apache SSHD Client (based on Apache SSHD 2.1.0) to forward 
> local sockets to target servers.
> Our client is configured to use NIO2 builtin service provider, NIO2 Mina 
> service provider and NIO2 Netty service provider.
> We have detected a leak of handles monitoring the java process with ALL above 
> NIO2 service provider.
> When the limit of handles per process is reached, the java process become 
> unresponsive.
>  
> We suspect that the problem could be into Apache SSHD Client code.
> The problem is reproducible in our lab environment.
>  
> Can you help us troubleshoot this problem and in that case what kind of info 
> you need ?
> Did you see a similar problem before and if so, can you give us a solution ?
>  
> Kind Regards
> Roberto Deandrea
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SSHD-908) Leak of process handles caused by local port forwarding connections

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-908:
-

I'll try and find some free time to investigate - though I am quite busy in the 
next weeks. You have not mentioned yet whether the problem is reproduced with 
version 2.2.0 and the program you attached.

> Leak of process handles caused by local port forwarding connections
> ---
>
> Key: SSHD-908
> URL: https://issues.apache.org/jira/browse/SSHD-908
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: repro.zip
>
>
> Hi,
> We have build an Apache SSHD Client (based on Apache SSHD 2.1.0) to forward 
> local sockets to target servers.
> Our client is configured to use NIO2 builtin service provider, NIO2 Mina 
> service provider and NIO2 Netty service provider.
> We have detected a leak of handles monitoring the java process with ALL above 
> NIO2 service provider.
> When the limit of handles per process is reached, the java process become 
> unresponsive.
>  
> We suspect that the problem could be into Apache SSHD Client code.
> The problem is reproducible in our lab environment.
>  
> Can you help us troubleshoot this problem and in that case what kind of info 
> you need ?
> Did you see a similar problem before and if so, can you give us a solution ?
>  
> Kind Regards
> Roberto Deandrea
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-338) Authentication with same krb5.keytab file works with OpenSSH and not with Apache MINA

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-338.
---
Resolution: Cannot Reproduce

> Authentication with same krb5.keytab file works with OpenSSH and not with 
> Apache MINA
> -
>
> Key: SSHD-338
> URL: https://issues.apache.org/jira/browse/SSHD-338
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 0.9.0, 0.11.0
> Environment: RedHat Enterprise Linux, RHEL 6.4 (x86_64), 
> 2.6.32-358.6.2.el6.x86_64 build 23093132
>Reporter: Christian Dröscher
>Priority: Minor
>
> In the krb5.keytab file I have four different key versions(KVNO) with the 
> same "host/** (aes256-cts-hmac-sha1-96)" - principial. OpenSSH can handle 
> this multiple entries and there are no authentication problems. But the 
> authentication with the same config, fails with Apache MINA. I deleted the 
> last two KVNO of the principial so that we have just two entries left. With 
> just two different KVNOs for the same principial, MINA is working as expected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-568) Update web site

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-568.
-
   Resolution: Fixed
Fix Version/s: 2.0.0

> Update web site
> ---
>
> Key: SSHD-568
> URL: https://issues.apache.org/jira/browse/SSHD-568
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff MAURY
>Priority: Major
>  Labels: release, site, web-site
> Fix For: 2.0.0
>
>
> Update web site to reflect the release of 1.1.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-474) Null pointer exception when connecting with latest Dropbear's dbclient

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-474.
---
Resolution: Cannot Reproduce

> Null pointer exception when connecting with latest Dropbear's dbclient
> --
>
> Key: SSHD-474
> URL: https://issues.apache.org/jira/browse/SSHD-474
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 0.14.0
> Environment: Apache SSHD 0.14.0 binary distribution on a Redhat 6 
> system.  Oracle Java 1.7.0_25.  Dropbear 2015.67.
>Reporter: Andrew Danforth
>Priority: Minor
> Attachments: dbclient.log, sshd.log
>
>
> SSHD throws a null pointer exception when using dbclient from Dropbear 
> 2015.67 to connect.  I believe this is due to dbclient attempting to reduce 
> message exchange during key negotiation.  If you compile dbclient and comment 
> out #define USE_KEX_FIRST_FOLLOWS from sysoptions.h the session proceeds as 
> expected.  FWIW, this version of dbclient has no issues interacting with an 
> OpenSSH daemon.
> I will attach a log of the SSHD output as well as the shell command to start 
> dbclient.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-479) Upgrade used Maven artifacts versions to more recent versions

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-479.
---
Resolution: Fixed

> Upgrade used Maven artifacts versions to more recent versions
> -
>
> Key: SSHD-479
> URL: https://issues.apache.org/jira/browse/SSHD-479
> Project: MINA SSHD
>  Issue Type: Dependency upgrade
>Reporter: Goldstein Lyor
>Priority: Minor
>
> Upgrade some versions to more recent releases - including used _Maven_ 
> plugins to build the project



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-709) All passwords should be stored as char[] instead of String and wiped after use

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-709.
---
Resolution: Won't Fix

> All passwords should be stored as char[] instead of String and wiped after use
> --
>
> Key: SSHD-709
> URL: https://issues.apache.org/jira/browse/SSHD-709
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (SSHD-745) KnownHostEntry cannot parse [host]:port or IPv6 with %link entries

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor resolved SSHD-745.
-
   Resolution: Fixed
Fix Version/s: 2.1.0

> KnownHostEntry cannot parse [host]:port or IPv6 with %link entries
> --
>
> Key: SSHD-745
> URL: https://issues.apache.org/jira/browse/SSHD-745
> Project: MINA SSHD
>  Issue Type: New Feature
>Affects Versions: 1.2.0
>Reporter: Stephen Connolly
>Priority: Minor
> Fix For: 2.1.0
>
>
> My known hosts file contains lines like: (note I have sanitized the lines and 
> switched entries to documentation reserved IP addresses and DNS names)
> {code}
> [host.example.com]:7999,[192.0.2.3]:7999 ssh-rsa ...Z45M/
> 2001:db8:85a3::8a2e:370:7334%en1 ecdsa-sha2-nistp256 E2...q9zmk=
> {code}
> Both of which will bomb out with errors like:
> {code}
> WARNING: Failed (StreamCorruptedException) to reload server keys from 
> /Users/stephenc/.ssh/known_hosts: Failed (IllegalArgumentException) to parse 
> line #96 '2001:db8:85a3::8a2e:370:7334%en1 ecdsa-sha2-nistp256 
> E2...q9zmk=': Invalid host pattern char in 
> 2001:db8:85a3::8a2e:370:7334%en1
> {code}
> or
> (This next one is a thrown away ssh server running in docker and the 
> container is gone so I can provide the full unedited line)
> {code}
> WARNING: Failed (StreamCorruptedException) to reload server keys from 
> /Users/stephenc/.ssh/known_hosts: Failed (IllegalArgumentException) to parse 
> line #60 '[127.0.0.1]:49153 ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQC5ntfSGAQOO2O/8ma7mtk9UaC6JWVlJ+6WAjnN3V510wc4nkkUcL66hZZyPLI0TYhk2CHNNQPeXkc6Cq7enSJab7SI06MhCQhF9yeuBQnphNBsUa01twPgycQOdrYey+4hIVXRF5BbckuU5nVAuFsPv7utNROmo+XoWoAdopSiejWs6Mrox+VIwgeN6peJ5l5jPqCjMEBTP9iNWgZMa+wQN7cTWpi7lIbK+a2hnzHz5P8oWFN8j8jREm+/6NK1IdW3c0CsLRWyee50GYYQOEi0zo1FfGweia5CbzfjRtfd0XFtUxGtULJpPoj9x/7xHuFUL1rYoKAGaTPzPdBHJTiJ':
>  Invalid host pattern char in [127.0.0.1]:49153
> {/code}
> https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files seems to 
> indicate that {{[host]:port}} is the syntax for when the ssh server is using 
> a non-standard port 
> https://serverfault.com/a/771355/147023 reports that the % at the end of the 
> IPv6 address is indicating the local link (in my case %en1 being WIFI on my 
> macbook, but I have seem %eth0 on modern linux servers)
> Completely blowing up for these entries seems rather wrong, I would expect 
> either skipping such entries or actually being able to parse them.
> Checking the current code on master it seems this issue has not been resolved 
> yet:
> IOW 
> https://github.com/apache/mina-sshd/blob/5b0b163c5500fedc2a6bae0fc5e260d64fcf370a/sshd-core/src/main/java/org/apache/sshd/client/config/hosts/HostPatternsHolder.java#L289-L306
>  still will reject a host name containing either the non-standard port 
> specification or the link specifier



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-809) Upgrade used unit tests version to jUnit 5

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-809.
---
Resolution: Won't Do

> Upgrade used unit tests version to jUnit 5
> --
>
> Key: SSHD-809
> URL: https://issues.apache.org/jira/browse/SSHD-809
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 1.7.0
>Reporter: Goldstein Lyor
>Priority: Major
>  Labels: frameworks, junit5, unit-test, upgrade
>
> See if it is easy to maintain backward compatibility - especially
>  * _getCurrentTestName()_
>  * {{@RunWith(JUnit4SingleInstanceClassRunner.class)}}
>  * 
> {{@UseParametersRunnerFactory(JUnit4ClassRunnerWithParametersFactory.class)}}
>  * {{@Category(\{ NoIoTestCase.class })}}
>  * Method (class (?)) order control
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-810) mina sshd 1.6.0, using as sftp server, run for about one month, found that there is too many ConcurrentHaspMap objects in Nio2Acceptor.

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-810.
---
Resolution: Won't Fix

> mina sshd 1.6.0, using as sftp server, run for about one month, found that 
> there is too many ConcurrentHaspMap  objects in Nio2Acceptor.
> 
>
> Key: SSHD-810
> URL: https://issues.apache.org/jira/browse/SSHD-810
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: young_shaw
>Priority: Blocker
>  Labels: memleak, sshd
> Attachments: memleak2.png
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> For example, the instance of "org.apache.sshd.common.io.nio2.Nio2Acceptor" 
> which adress is "0x732137c40" occupies 2,224,510,720 (71.65%) bytes.Its 
> memory is mainly accumulated by the instance of 
> "java.util.concurrent.ConcurrentHashMap$Node[]" "0x744a55fb8" loaded by the 
> class "bootstrap class loader".
> I am wondering where can I close and destory the Nio2Session. Please help me, 
> thank you.
> !memleak2.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-853) Support for Diffie-Hellman 3072 for key exchange

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-853.
---
Resolution: Not A Problem

> Support for Diffie-Hellman 3072 for key exchange
> 
>
> Key: SSHD-853
> URL: https://issues.apache.org/jira/browse/SSHD-853
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: chris ullock
>Priority: Major
> Attachments: CNSA-Suite-and-Quantum-Computing-FAQ.pdf
>
>
> as per NSA 2016 guidelines, recommendation is to support Diffie-Hellman 3072 
> for key exchange: 
> [https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-854) Massive object graph in NioSocketSession

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-854.
---
Resolution: Cannot Reproduce

> Massive object graph in NioSocketSession
> 
>
> Key: SSHD-854
> URL: https://issues.apache.org/jira/browse/SSHD-854
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: jpalacios
>Priority: Major
>
> I'm looking at a heap dump from one of our customers where the retained heap 
> size for some {{NioSocketSession}} instances is almost 1GB.
> From the looks of the dump MINA has created a massive object graph where:
> {code}
> NioSocketSession -> SelectionKeyImpl -> EpollSelectorImpl -> HashMap -> 
> SelectionKeyImpl -> NioSocketSession -> ...
> {code}
> From the looks of the obeject IDs these are not loops
> Each individual object is not large by itself but at the top of the graph the 
> accumulated retained size is enough to produce an OOME
> Could you help me understand how MINA can produce such a massive object 
> graph? Should MINA apply any defense mechanism to prevent this??



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-880) Migrating from jsch to apache mina for ANT

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-880.
---
Resolution: Won't Fix

> Migrating from jsch to apache mina for ANT
> --
>
> Key: SSHD-880
> URL: https://issues.apache.org/jira/browse/SSHD-880
> Project: MINA SSHD
>  Issue Type: Question
>Reporter: Sharat Chandran
>Priority: Major
>
> We wanted to use apache mina for doing ssh tasks from within ant (instead of 
> using jsch). 
> Is this possible? If yes, do you have a set of steps which we should follow 
> to get this done?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-888) Maven artefacts sshd-core and sshd-common share common package names.

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-888.
---
Resolution: Won't Fix

> Maven artefacts sshd-core and sshd-common share common package names.
> -
>
> Key: SSHD-888
> URL: https://issues.apache.org/jira/browse/SSHD-888
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Keve Müller
>Priority: Major
>
> The maven artefacts for SSHD share common package names which make them very 
> hard to use in a Jigsaw modularized project. Jigsaw does not allow modules to 
> have the same package names.
> Suggestion:
> Either join these into a single artefact (simple) or refactor the code to use 
> disjoint package names (hard).
> Additionally, add
> {code:java}
>  Automatic-Module-Name org.apache.sshd{code}
>  to the manifest, to provide for a stable name for the module.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-884) Release plan?

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-884.
---
   Resolution: Fixed
Fix Version/s: 2.2.0

> Release plan?
> -
>
> Key: SSHD-884
> URL: https://issues.apache.org/jira/browse/SSHD-884
> Project: MINA SSHD
>  Issue Type: Question
>Reporter: Thomas Wolf
>Priority: Major
> Fix For: 2.2.0
>
>
> Is there a release plan for Apache MINA sshd somewhere where users could 
> learn when new releases are planned to be made?
> I've seen a mention in SSHD-861 that the next version (2.2.0 ?) would 
> probably come "Q1 2019"? Would it be possible to have an sshd 2.2.0 in the 
> maven repositories by mid-February?
> I'd very much like to update the integration in Eclipse (EGit/JGit) to sshd 
> 2.2.0 for the next EGit release, which is on 2019-03-20. There've been quite 
> a few fixes and improvements I'd like to see in Eclipse, too. For that I'd 
> need to have maven artifacts available by mid-February at the latest. 
> Otherwise we'll have to wait another three months.
> [Related EGit issue|https://bugs.eclipse.org/bugs/show_bug.cgi?id=541425].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SSHD-891) SSh connections gets closed for every one hour with 0.13.0 version

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor closed SSHD-891.
---
Resolution: Won't Fix

> SSh connections gets closed for every one hour with 0.13.0 version
> --
>
> Key: SSHD-891
> URL: https://issues.apache.org/jira/browse/SSHD-891
> Project: MINA SSHD
>  Issue Type: Bug
>Reporter: Anudeep
>Assignee: Goldstein Lyor
>Priority: Blocker
>
> SSH connections are getting closed for every one hours after 10 mins of idle 
> time even though there are incoming pacets data is not being wriiten to 
> client for every one hour and is being idle(10 mins which is default timeout 
> of ssh session).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)