[jira] [Resolved] (SSHD-1237) SftpClient logs warnings on keepalive messages
[
https://issues.apache.org/jira/browse/SSHD-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1237.
---
Fix Version/s: 2.13.0
Resolution: Fixed
PR 492 merged.
> SftpClient logs warnings on keepalive messages
> --
>
> Key: SSHD-1237
> URL: https://issues.apache.org/jira/browse/SSHD-1237
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Jens Grassel
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.13.0
>
>
> Hi,
> we just noticed that using the default SshClient we get lots of warning
> messages in our logs about keep alive requests like this:
> {noformat}
> 08:55:32.122 [sshd-SshClient[40b05dd]-nio2-thread-2] WARN
> o.a.s.s.c.i.DefaultSftpClient$SftpChannelSubsystem -
> handleUnknownChannelRequest(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[XXX@XXX/XXX:22][sftp]) Unknown channel
> request: keepal...@openssh.com[want-reply=true]
> {noformat}
> We're using the {{SshClient.setUpDefaultClient()}} function then create our
> session and finally use the {{createSftpClient(session)}} function on a
> SftpClientFactory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1259) DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in known_hosts
[
https://issues.apache.org/jira/browse/SSHD-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1259:
--
Fix Version/s: 2.11.0
> DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in
> known_hosts
> -
>
> Key: SSHD-1259
> URL: https://issues.apache.org/jira/browse/SSHD-1259
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Klaus Nguetsa
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> Hello everyone,
> Assuming I have the following known_hosts file containing twice the public
> key of the same host but with different algorithms.:
>
> {code:java}
> lserver1 ssh-dss
>
> #
> lserver1 ecdsa-sha2-nistp256
> {code}
>
>
> During the connection when I use DefaultKnownHostsServerKeyVerifier to
> verify the keys, if the target host presents a ecdsa-sha2-nistp256 key, the
> verification will fail because DefaultKnownHostsServerKeyVerifier seems to
> match to the first occurence of the hostname in the know_host file. Therefore
> It will match the key _lserver1 ssh-dss ..._ and the comparison
> to the same key but with ecdsa-sha2-nistp256 algorithm presented by the
> target host will fail. Shouldn't it iterate through the file until the right
> combination (hostname, algorithm) is found? This way it could check with
> lserver1 ecdsa-sha2-nistp256 . instead of lserver1 ssh-dss X..
> This works fine with openssh.
> Thanks
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[
https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1310:
--
Fix Version/s: 2.11.0
> SftpFileSystem.close() method, closes the session as well.
> ---
>
> Key: SSHD-1310
> URL: https://issues.apache.org/jira/browse/SSHD-1310
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Tilden
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> SftpFileSystem.close() method, closes the session as well.
> We expect only the sftpfilesystem channel to be closed. Since we use the
> same session for multiple operations (exec command, SFTP download & upload,
> SFTP client list directory).
>
> SftpFileSystem.java
> public void close() throws IOException {
> if (this.isOpen()) {
> SftpFileSystemProvider provider = this.provider();
> String fsId = this.getId();
> SftpFileSystem fs = provider.removeFileSystem(fsId);
> ClientSession session = this.getClientSession();
> *session.close(true);*
> if (fs != null && fs != this) {
> throw new FileSystemException(fsId, fsId, "Mismatched FS
> instance for id=" + fsId);
> }
> }
> }
>
>
> can you please check and let us know, if this can be fixed ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1332:
--
Fix Version/s: 2.10.1
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1, 2.11.0
>
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1327) WriteState causes memory overflow
[ https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf updated SSHD-1327: -- Fix Version/s: 2.11.0 > WriteState causes memory overflow > - > > Key: SSHD-1327 > URL: https://issues.apache.org/jira/browse/SSHD-1327 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.10.0 >Reporter: fuzhoupeng >Assignee: Thomas Wolf >Priority: Major > Fix For: 2.10.1, 2.11.0 > > Attachments: image-2023-05-16-09-58-04-005.png, > image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png, > image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png, > image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png, > image-2023-05-16-10-12-23-189.png > > > When data is written to a channel, the writeBuffer method is invoked, and a > writeState is recorded. > !image-2023-05-16-10-03-44-339.png! > > WriteState records the last sent packet, which causes memory overflow. > !image-2023-05-16-10-04-31-679.png! > !image-2023-05-16-10-06-12-880.png! > > When a large number of devices are managed and a large number of packets are > delivered last time, the cached packets delivered last time cause service > memory overflow. > !image-2023-05-16-10-12-13-163.png! > !image-2023-05-16-10-12-23-189.png! > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1330:
--
Fix Version/s: 2.10.1
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.10.1, 2.11.0
>
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1330:
--
Fix Version/s: 2.11.0
(was: 2.10.1)
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.11.0
>
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1332:
--
Fix Version/s: 2.11.0
(was: 2.10.1)
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.11.0
>
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1335) Add landing directory feature
[
https://issues.apache.org/jira/browse/SSHD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767695#comment-17767695
]
Thomas Wolf commented on SSHD-1335:
---
It depends. If the user should only be able to access {{/A/B}} via SFTP, then
just set that as his home directory in
{{{}VirtualFileSystemFactory.setUserHomeDir(){}}}. It does not have to be the
user's real home directory in the operating system.
But if the user should also be able to access {{/A}} via SFTP, then what you
want is not doable server-side. Commands like {{cd}} or {{pwd}} must be
implemented client-side; and doing an initial "{{{}cd B{}}}" after log-in would
also have to happen in the client.
> Add landing directory feature
> -
>
> Key: SSHD-1335
> URL: https://issues.apache.org/jira/browse/SSHD-1335
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ananth kumar
>Priority: Critical
>
> Currently, we are able to set only the home directory using the
> VirtualFileSystemFactory class.
> Our requirement is to land the user in the subdirectories of the home
> directory.
> Is some feature can be provided to land the user in a different directory?
> Eg:
> The User A has the home directory as /A. But the User A should be landed into
> the /A/B directory after login
> Current scenario:
> {code:java}
> sftp> pwd
> /{code}
> required Scenario:
> {code:java}
> sftp> pwd
> /B {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1335) Add landing directory feature
[
https://issues.apache.org/jira/browse/SSHD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766877#comment-17766877
]
Thomas Wolf commented on SSHD-1335:
---
AFAIK there is no server-side concept of a "current working directory" in SFTP.
You could set the user's SFTP root directory (his "SFTP home directory") to
{{/A/B}} in the {{{}VirtualFileSystemFactory{}}}, but then the the SFTP path
"/" would refer to {{{}/A/B{}}}, and {{pwd}} on the client would still show "/"
after login.
> Add landing directory feature
> -
>
> Key: SSHD-1335
> URL: https://issues.apache.org/jira/browse/SSHD-1335
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ananth kumar
>Priority: Critical
>
> Currently, we are able to set only the home directory using the
> VirtualFileSystemFactory class.
> Our requirement is to land the user in the subdirectories of the home
> directory.
> Is some feature can be provided to land the user in a different directory?
> Eg:
> The User A has the home directory as /A. But the User A should be landed into
> the /A/B directory after login
> Current scenario:
> {code:java}
> sftp> pwd
> /{code}
> required Scenario:
> {code:java}
> sftp> pwd
> /B {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1332.
---
Fix Version/s: 2.10.1
Resolution: Fixed
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1
>
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739291#comment-17739291
]
Thomas Wolf commented on SSHD-1329:
---
I just spent some two hours to set up a VirtualBox VM with Ubuntu 22.04.2 LTS
from scratch to test this.
Your test works perfectly for me out of the box, using Apache MINA sshd 2.10.0,
Java 17, on Ubuntu 22.04.2 and an Apache MINA sshd test server. The client can
authenticate just fine at the server.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739277#comment-17739277
]
Thomas Wolf commented on SSHD-1329:
---
Maybe this a red herring, but... perhaps check the crypto policies on your
Ubuntu 22.04. AFAIK Ubuntu 22.04 disables SHA1 signatures with RSA keys via
crypto policies, and that may affect also the JDK. See
[https://manpages.ubuntu.com/manpages/jammy/en/man8/update-crypto-policies.8.html]
. I don't quite see how that could lead to not being able to find or load the
key in the first place, but it's still something to check.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533
[jira] [Commented] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739194#comment-17739194
]
Thomas Wolf commented on SSHD-1332:
---
Yes indeed. [PR 394|https://github.com/apache/mina-sshd/pull/394] should fix
this.
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1332) Identities using tilde specified in config are not loaded
[
https://issues.apache.org/jira/browse/SSHD-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1332:
-
Assignee: Thomas Wolf
> Identities using tilde specified in config are not loaded
> -
>
> Key: SSHD-1332
> URL: https://issues.apache.org/jira/browse/SSHD-1332
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Bernhard Geisberger
>Assignee: Thomas Wolf
>Priority: Major
>
> In the latest version of sshd, the library fails to load any identities
> specified in the {{.ssh/config}} file if they use tilde in their path (e.g.
> {{~/.ssh/id_test}}).
> This seems to be a regression from
> [https://github.com/apache/mina-sshd/pull/353] because the
> {{resolveIdentityFilePath}} method inside {{HostConfigEntry}} is no longer
> called.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738281#comment-17738281
]
Thomas Wolf commented on SSHD-1331:
---
I read this statement from the RFC a bit differently. The first algorithm in
the client's list that the server also supports is {{{}ssh-rsa{}}}, so that is
the algorithm that should be used.
The fix in an Apache MINA sshd client is to simply ensure that rsa-sha2-512
comes before rsa-sha2-256 comes before ssh-rsa. Which is the default setup.
Compare also SSHD-1325.
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
> that case the guess is not successful and there's defined algorithm that must
> be followed (basically, client iterating over the common list of algorithms
> until finding the correct match) -
> [https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
> This seems to not be the case though as the exception says that the signature
> verification failed for *ssh-rsa,* I would expect the implementation to
> iterate to the *rsa-sha2-512* and match the server's guessed algorithm.
> How is this handled in Mina SSHD implementation? Is this something I can
> override/handle in my own implementation? Can someone point me in the right
> direction please?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738272#comment-17738272
]
Thomas Wolf commented on SSHD-1329:
---
Interesting indeed. I have no Ubuntu 22.04 readily available; I would have to
set up a VM, then set up a development environment, then see if I could
reproduce in that VM, then debug.
I see two possibilities:
* the file is found, but the key cannot be read and somehow no exception is
thrown, or it isn't being logged. Try setting a breakpoint in
RSAPEMResourceKeyPairParser.extractKeyPairs(). If you do get there, then step
through starting at that location.
* or the file isn't found in the first place -- in that case, check the umask
and make sure the file is readable. Set a breakpoint at
SecurityUtils.loadKeyPairIdentities(), then verify that the file exists and is
readable, and step through from there.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735544#comment-17735544
]
Thomas Wolf commented on SSHD-1329:
---
{quote}the issue seems to be with the SSH key loading{quote}
That was clear. But still: I cannot reproduce the problem.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: sshd-bug-test.tgz
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=password
> 2023-06-19T13:13:41,534 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.password.UserAuthPassword [] -
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735464#comment-17735464
]
Thomas Wolf commented on SSHD-1329:
---
{quote}Client is running Ubuntu 22.04.2 LTS on x86.{quote}
So not a Windows-specific problem.
I've tried by now Java 8, Java 17, with or without BouncyCastle. No problems so
far.
Do you have a {{~/.ssh/config file}} with a host entry for that Fritzbox?
(And of course I don't have a Fritzbox. I'm testing against against an Apache
MINA sshd server. But given your log excerpt, it doesn't look like the kind of
server should have any impact.)
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: sshd-bug-test.tgz
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735361#comment-17735361
]
Thomas Wolf commented on SSHD-1329:
---
{quote}... works fine regardless of putting 2.10.0 or 2.9.2 in the pom.xml
?{quote}
Yes. The client can authenticate successfully.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: sshd-bug-test.tgz
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=password
> 2023-06-19T13:13:41,534 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.password.UserAuthPassword [] -
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735164#comment-17735164
]
Thomas Wolf commented on SSHD-1329:
---
Cannot reproduce so far. I'll keep looking, though. What OS is the client on?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: sshd-bug-test.tgz
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=password
> 2023-06-19T13:13:41,534 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.password.UserAuthPassword [] -
> resolveAttemptedPassword(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
>
[jira] [Closed] (SSHD-1328) Hanging while executing rsync commands.
[
https://issues.apache.org/jira/browse/SSHD-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf closed SSHD-1328.
-
I cannot fix your code. I thought I had pointed out what I thought was wrong,
and that implies a solution: read those output/error streams right away, don't
wait until the channel is closed. The {{rsync}} probably produces lots of
output; once {{stdout}} buffers are full, the {{rsync}} will block because it
cannot write output anymore.
> Hanging while executing rsync commands.
>
>
> Key: SSHD-1328
> URL: https://issues.apache.org/jira/browse/SSHD-1328
> Project: MINA SSHD
> Issue Type: Bug
> Environment: Linux and Solaris
>Reporter: sivaprasad
>Priority: Blocker
>
> Hi Team,
> I hope all are doing great, I'm using Mina to execute remote commands
> execution and file uploads/downloads. everything is working fine, but while
> executing rsync commands( this command will take more than 1hr to complete)
> Mina is hanging forever and not returning anything.
> I have added HEARTBEAT in my code, but Mina is printing command output after
> command execution is completed but I need to print command output parallel
> with command execution.
> I have attached my code, can someone look into this and help me to resolve
> this issue’s.
>
> Thanks,
> Siva.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1328) Hanging while executing rsync commands.
[ https://issues.apache.org/jira/browse/SSHD-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1328. --- Resolution: Not A Bug This code opens a channel and then waits until the channel is closed, and only then starts reading the output/error streams. So the behavior you are seeing is expected. And the remote command may hang once it cannot write any more output because the client side isn't reading. This will happen once the channel window has been exhausted. Setting the heartbeat on the client or the session is sufficient. The global request handler is unnecessary. > Hanging while executing rsync commands. > > > Key: SSHD-1328 > URL: https://issues.apache.org/jira/browse/SSHD-1328 > Project: MINA SSHD > Issue Type: Bug > Environment: Linux and Solaris >Reporter: sivaprasad >Priority: Blocker > > Hi Team, > I hope all are doing great, I'm using Mina to execute remote commands > execution and file uploads/downloads. everything is working fine, but while > executing rsync commands( this command will take more than 1hr to complete) > Mina is hanging forever and not returning anything. > I have added HEARTBEAT in my code, but Mina is printing command output after > command execution is completed but I need to print command output parallel > with command execution. > I have attached my code, can someone look into this and help me to resolve > this issue’s. > > Thanks, > Siva. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1259) DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in known_hosts
[
https://issues.apache.org/jira/browse/SSHD-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1259.
---
Fix Version/s: 2.10.1
Resolution: Fixed
[PR 368|https://github.com/apache/mina-sshd/pull/368] merged.
> DefaultKnownHostsServerKeyVerifier not checking all Key algorithms present in
> known_hosts
> -
>
> Key: SSHD-1259
> URL: https://issues.apache.org/jira/browse/SSHD-1259
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Klaus Nguetsa
>Priority: Major
> Fix For: 2.10.1
>
>
> Hello everyone,
> Assuming I have the following known_hosts file containing twice the public
> key of the same host but with different algorithms.:
>
> {code:java}
> lserver1 ssh-dss
>
> #
> lserver1 ecdsa-sha2-nistp256
> {code}
>
>
> During the connection when I use DefaultKnownHostsServerKeyVerifier to
> verify the keys, if the target host presents a ecdsa-sha2-nistp256 key, the
> verification will fail because DefaultKnownHostsServerKeyVerifier seems to
> match to the first occurence of the hostname in the know_host file. Therefore
> It will match the key _lserver1 ssh-dss ..._ and the comparison
> to the same key but with ecdsa-sha2-nistp256 algorithm presented by the
> target host will fail. Shouldn't it iterate through the file until the right
> combination (hostname, algorithm) is found? This way it could check with
> lserver1 ecdsa-sha2-nistp256 . instead of lserver1 ssh-dss X..
> This works fine with openssh.
> Thanks
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[
https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1310.
---
Fix Version/s: 2.10.1
Resolution: Fixed
[PR 377|https://github.com/apache/mina-sshd/pull/377] merged.
> SftpFileSystem.close() method, closes the session as well.
> ---
>
> Key: SSHD-1310
> URL: https://issues.apache.org/jira/browse/SSHD-1310
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Tilden
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.1
>
>
> SftpFileSystem.close() method, closes the session as well.
> We expect only the sftpfilesystem channel to be closed. Since we use the
> same session for multiple operations (exec command, SFTP download & upload,
> SFTP client list directory).
>
> SftpFileSystem.java
> public void close() throws IOException {
> if (this.isOpen()) {
> SftpFileSystemProvider provider = this.provider();
> String fsId = this.getId();
> SftpFileSystem fs = provider.removeFileSystem(fsId);
> ClientSession session = this.getClientSession();
> *session.close(true);*
> if (fs != null && fs != this) {
> throw new FileSystemException(fsId, fsId, "Mismatched FS
> instance for id=" + fsId);
> }
> }
> }
>
>
> can you please check and let us know, if this can be fixed ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Reopened] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[
https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reopened SSHD-1310:
---
Assignee: Thomas Wolf
Re-opening.
Actually, yes, an {{SftpFileSystem}} is intended to be used in a session. But
there are two cases:
# The {{SftpFileSystemProvider}} provides the file system. In that case, the
session created by the {{SftpFileSystemProvider}} is owned by the
{{SftpFileSystem}} and _must_ be closed when the file system is closed.
# Client code has already a {{ClientSession}} and creates the file system
directly via {{SftpClientFactory.instance().createSftpFileSystem()}}. In that
case the session _must not_ be closed when the {{SftpFileSystem}} is closed.
> SftpFileSystem.close() method, closes the session as well.
> ---
>
> Key: SSHD-1310
> URL: https://issues.apache.org/jira/browse/SSHD-1310
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Tilden
>Assignee: Thomas Wolf
>Priority: Major
>
> SftpFileSystem.close() method, closes the session as well.
> We expect only the sftpfilesystem channel to be closed. Since we use the
> same session for multiple operations (exec command, SFTP download & upload,
> SFTP client list directory).
>
> SftpFileSystem.java
> public void close() throws IOException {
> if (this.isOpen()) {
> SftpFileSystemProvider provider = this.provider();
> String fsId = this.getId();
> SftpFileSystem fs = provider.removeFileSystem(fsId);
> ClientSession session = this.getClientSession();
> *session.close(true);*
> if (fs != null && fs != this) {
> throw new FileSystemException(fsId, fsId, "Mismatched FS
> instance for id=" + fsId);
> }
> }
> }
>
>
> can you please check and let us know, if this can be fixed ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1327) WriteState causes memory overflow
[ https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1327. --- Fix Version/s: 2.10.1 Resolution: Fixed > WriteState causes memory overflow > - > > Key: SSHD-1327 > URL: https://issues.apache.org/jira/browse/SSHD-1327 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.10.0 >Reporter: fuzhoupeng >Assignee: Thomas Wolf >Priority: Major > Fix For: 2.10.1 > > Attachments: image-2023-05-16-09-58-04-005.png, > image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png, > image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png, > image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png, > image-2023-05-16-10-12-23-189.png > > > When data is written to a channel, the writeBuffer method is invoked, and a > writeState is recorded. > !image-2023-05-16-10-03-44-339.png! > > WriteState records the last sent packet, which causes memory overflow. > !image-2023-05-16-10-04-31-679.png! > !image-2023-05-16-10-06-12-880.png! > > When a large number of devices are managed and a large number of packets are > delivered last time, the cached packets delivered last time cause service > memory overflow. > !image-2023-05-16-10-12-13-163.png! > !image-2023-05-16-10-12-23-189.png! > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1327) WriteState causes memory overflow
[ https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf updated SSHD-1327: -- Affects Version/s: 2.10.0 > WriteState causes memory overflow > - > > Key: SSHD-1327 > URL: https://issues.apache.org/jira/browse/SSHD-1327 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.10.0 >Reporter: fuzhoupeng >Assignee: Thomas Wolf >Priority: Major > Attachments: image-2023-05-16-09-58-04-005.png, > image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png, > image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png, > image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png, > image-2023-05-16-10-12-23-189.png > > > When data is written to a channel, the writeBuffer method is invoked, and a > writeState is recorded. > !image-2023-05-16-10-03-44-339.png! > > WriteState records the last sent packet, which causes memory overflow. > !image-2023-05-16-10-04-31-679.png! > !image-2023-05-16-10-06-12-880.png! > > When a large number of devices are managed and a large number of packets are > delivered last time, the cached packets delivered last time cause service > memory overflow. > !image-2023-05-16-10-12-13-163.png! > !image-2023-05-16-10-12-23-189.png! > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1327) WriteState causes memory overflow
[ https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf reassigned SSHD-1327: - Assignee: Thomas Wolf > WriteState causes memory overflow > - > > Key: SSHD-1327 > URL: https://issues.apache.org/jira/browse/SSHD-1327 > Project: MINA SSHD > Issue Type: Bug >Reporter: fuzhoupeng >Assignee: Thomas Wolf >Priority: Major > Attachments: image-2023-05-16-09-58-04-005.png, > image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png, > image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png, > image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png, > image-2023-05-16-10-12-23-189.png > > > When data is written to a channel, the writeBuffer method is invoked, and a > writeState is recorded. > !image-2023-05-16-10-03-44-339.png! > > WriteState records the last sent packet, which causes memory overflow. > !image-2023-05-16-10-04-31-679.png! > !image-2023-05-16-10-06-12-880.png! > > When a large number of devices are managed and a large number of packets are > delivered last time, the cached packets delivered last time cause service > memory overflow. > !image-2023-05-16-10-12-13-163.png! > !image-2023-05-16-10-12-23-189.png! > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1327) WriteState causes memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723734#comment-17723734
]
Thomas Wolf commented on SSHD-1327:
---
[PR 374|https://github.com/apache/mina-sshd/pull/374] set that {{lastWrite}} to
{{null}} when the future is done (i.e., when the whole buffer has been written).
> WriteState causes memory overflow
> -
>
> Key: SSHD-1327
> URL: https://issues.apache.org/jira/browse/SSHD-1327
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: fuzhoupeng
>Priority: Major
> Attachments: image-2023-05-16-09-58-04-005.png,
> image-2023-05-16-10-03-30-225.png, image-2023-05-16-10-03-44-339.png,
> image-2023-05-16-10-04-31-679.png, image-2023-05-16-10-04-53-165.png,
> image-2023-05-16-10-06-12-880.png, image-2023-05-16-10-12-13-163.png,
> image-2023-05-16-10-12-23-189.png
>
>
> When data is written to a channel, the writeBuffer method is invoked, and a
> writeState is recorded.
> !image-2023-05-16-10-03-44-339.png!
>
> WriteState records the last sent packet, which causes memory overflow.
> !image-2023-05-16-10-04-31-679.png!
> !image-2023-05-16-10-06-12-880.png!
>
> When a large number of devices are managed and a large number of packets are
> delivered last time, the cached packets delivered last time cause service
> memory overflow.
> !image-2023-05-16-10-12-13-163.png!
> !image-2023-05-16-10-12-23-189.png!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1326) Failed to establish an SSH connection because the server identifier exceeds the int range
[ https://issues.apache.org/jira/browse/SSHD-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1326. --- Fix Version/s: 2.10.0 Resolution: Fixed This is a duplicate of [GitHub issue 300|https://github.com/apache/mina-sshd/issues/300], which was fixed on 2023-01-02. The fix is in 2.10.0, which is about to be released. > Failed to establish an SSH connection because the server identifier exceeds > the int range > - > > Key: SSHD-1326 > URL: https://issues.apache.org/jira/browse/SSHD-1326 > Project: MINA SSHD > Issue Type: Bug >Reporter: fuzhoupeng >Priority: Major > Fix For: 2.10.0 > > Attachments: image-2023-05-15-22-37-13-132.png, > image-2023-05-15-22-38-27-120.png, image-2023-05-15-22-39-31-313.png, > image-2023-05-15-22-41-11-404.png, image-2023-05-15-22-41-49-254.png > > > When the channel is enabled, the server identifier is set to uint. > !image-2023-05-15-22-41-11-404.png! > > However, channelOpenConfirmation uses int to obtain the identifier of the > server. If the unit sent by the server exceeds the int range, the value is an > incorrect value. As a result, the subsequent process fails > !image-2023-05-15-22-37-13-132.png! > > ChannelOpen has changed here. The place above may have forgotten to change. > !image-2023-05-15-22-41-49-254.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721491#comment-17721491
]
Thomas Wolf commented on SSHD-1325:
---
I quite agree that documentation could be improved. A simple flag for including
the deprecated algorithms in the default setup might perhaps also help, or in
fact always include them in the client-side setup, but never in the server-side
setup.
Clients typically want to be compatible also with older servers, so they want
to include old algorithms. In fact, in JGit I had done exactly that when Apache
MINA sshd deprecated dsa and rsa. See
[https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/refs/heads/master/org.eclipse.jgit.ssh.apache/src/org/eclipse/jgit/transport/sshd/SshdSessionFactory.java#627]
.
> Not useful sorting of signature algrithms?
> --
>
> Key: SSHD-1325
> URL: https://issues.apache.org/jira/browse/SSHD-1325
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jan Philipp
>Priority: Major
>
> We found the current (default) settings may result into authentication
> problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods
> available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS
> (well, actually, on the crypto (default) settings). The same key and the same
> destination host *will* work when using the "native" OpenSSH client.
>
> The actual culprit is the deprecation of RSA+SHA1 issue which already have
> some issue stories here at Jira also :) Basically the usage of RSA keys is
> still fine, but the usage of SHA1 will be disallowed and this is enforced by
> modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}},
> {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When
> using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and
> this is always {{{}RSA with SHA1{}}}.
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat
> {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this.
> That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked
> (because the order of appearance is used for matching). If the match finder
> is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the
> non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet
> this.
>
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
> BuiltinSignatures.dsa,
> BuiltinSignatures.dsa_cert,
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
> Stream.concat(
> BuiltinSignatures.VALUES.stream()
> .filter(not(deprecated::contains)),
> deprecated.stream()
> )
> .map(s -> (NamedFactory) s)
> .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
> # Is this workaround actually correct or have I missed something which could
> be an issue in the future?
> # I can see a growing issue of "mina does not work" because if seems to
> break with default settings. IMHO either the order (like the workaround) must
> be changed or the matcher should look for other matches also (which he does
> not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but
> seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This
> does not seem to be solved in 2.9. If I have missed something, please correct
> me.
> A full demo is available in my repo-demo at
> [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses
> Testcontainers for spinning up the samples, so you need Docker or something
> compatible.
> The demo contains 2x2 tests against a container with Oracle Linux 8
> respective 9 configured with password respective with a RSA public key. OL8
> works fine, and password also. Only the "modern" OL9 with an RSA public key
> fails. I've added an additiona test `run2` with the enabled workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721061#comment-17721061
]
Thomas Wolf commented on SSHD-1325:
---
I don't understand. If the {{ClientBuilder}} is used, the default signature
order will be the one from {{BaseBuilder.DEFAULT_SIGNATURE_PREFERENCE}}. See
{{ClientBuilder.setUpDefaultSignatureFactories()}}. These default settings _do_
work.
We did notice in Eclipse before that if you include ssh-rsa in the KEX
proposal, it should come _after_ rsa-sha2-512, rsa-sha2-256. Otherwise some SSH
servers may wrongly decide on the wrong signature. But your issue is not about
KEX...
{{BuiltinSignatures.VALUES}} is a {{Set}}. Therefore, _no_ particular order is
guaranteed, so code using it should not assume any particular order. Likewise,
the order of the enumeration constants in {{BuiltinSignatures}} it unrelated to
any order that might make sense for {{PubkeyAcceptedAlgorithms}}.
> Not useful sorting of signature algrithms?
> --
>
> Key: SSHD-1325
> URL: https://issues.apache.org/jira/browse/SSHD-1325
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jan Philipp
>Priority: Major
>
> We found the current (default) settings may result into authentication
> problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods
> available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS
> (well, actually, on the crypto (default) settings). The same key and the same
> destination host *will* work when using the "native" OpenSSH client.
>
> The actual culprit is the deprecation of RSA+SHA1 issue which already have
> some issue stories here at Jira also :) Basically the usage of RSA keys is
> still fine, but the usage of SHA1 will be disallowed and this is enforced by
> modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}},
> {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When
> using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and
> this is always {{{}RSA with SHA1{}}}.
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat
> {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this.
> That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked
> (because the order of appearance is used for matching). If the match finder
> is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the
> non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet
> this.
>
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
> BuiltinSignatures.dsa,
> BuiltinSignatures.dsa_cert,
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
> Stream.concat(
> BuiltinSignatures.VALUES.stream()
> .filter(not(deprecated::contains)),
> deprecated.stream()
> )
> .map(s -> (NamedFactory) s)
> .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
> # Is this workaround actually correct or have I missed something which could
> be an issue in the future?
> # I can see a growing issue of "mina does not work" because if seems to
> break with default settings. IMHO either the order (like the workaround) must
> be changed or the matcher should look for other matches also (which he does
> not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but
> seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This
> does not seem to be solved in 2.9. If I have missed something, please correct
> me.
> A full demo is available in my repo-demo at
> [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses
> Testcontainers for spinning up the samples, so you need Docker or something
> compatible.
> The demo contains 2x2 tests against a container with Oracle Linux 8
> respective 9 configured with password respective with a RSA public key. OL8
> works fine, and password also. Only the "modern" OL9 with an RSA public key
> fails. I've added an additiona test `run2` with the enabled workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional
[jira] [Commented] (SSHD-1322) How to identify received LSTAT command is part of PUT command at Server
[ https://issues.apache.org/jira/browse/SSHD-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713257#comment-17713257 ] Thomas Wolf commented on SSHD-1322: --- I don't think you can. The LSTAT comes from OpenSSH querying [whether is a directory|https://github.com/openssh/openssh-portable/blob/ac383f3a5/sftp.c#L747]. > How to identify received LSTAT command is part of PUT command at Server > > > Key: SSHD-1322 > URL: https://issues.apache.org/jira/browse/SSHD-1322 > Project: MINA SSHD > Issue Type: Question >Reporter: Sreedhar J >Priority: Major > > From SFTP client, when I execute PUT , > SFTP Server recieves first LS command SSH_FXP_LSTAT followed by PUT > commands ( SSH_FXP_OPEN, SSH_FXP_WRITE ). > where as if we issue PUT < local file>, Server would get the commands as > SSH_FXP_OPEN, SSH_FXP_WRITE > *So, my question is,at Server level LSTAT command was invoked as part > of embeeded PUT command vs normal LSTAT command from sftp client.* -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1319) SftpRemotePathChannel.transferFrom(...) ignores position argument
[
https://issues.apache.org/jira/browse/SSHD-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1319:
--
Fix Version/s: 2.10.0
(was: 2.9.3)
> SftpRemotePathChannel.transferFrom(...) ignores position argument
> -
>
> Key: SSHD-1319
> URL: https://issues.apache.org/jira/browse/SSHD-1319
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Andreas Bergander
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.0
>
>
> The _position_ argument in the _SftpRemotePathChannel.transferFrom(...)_
> method seems only to be used when validating it and in debug logging.
> It should also affect where the data is written to the remote file. Perhaps
> it could be fixed with adding a call to
> {_}SftpOutputStreamAsync.setOffset(...){_}?
> {code:java}
> output.setOffset(position);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1316) Possible OOM in ChannelPipedInputStream
[ https://issues.apache.org/jira/browse/SSHD-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf updated SSHD-1316: -- Fix Version/s: 2.10.0 (was: 2.9.3) > Possible OOM in ChannelPipedInputStream > --- > > Key: SSHD-1316 > URL: https://issues.apache.org/jira/browse/SSHD-1316 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Evgeny Pasynkov >Assignee: Thomas Wolf >Priority: Major > Fix For: 2.10.0 > > > Hi, > Using Mina SSHD as a client, I sometimes experience the OutOfMemory in > ChannelPipedInputStream. The problem occurs when client reads data from > backing buffer slower than channel pushes data from socket into stream, so > the `ChannelPipedInputStream.buffer` grows beyond memory limits. > Could you please support limit for the backing buffer and throttle when it > overflows? > Thank you in advance -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1315) Password in clear in SSHD server's logs
[
https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1315:
--
Fix Version/s: 2.10.0
(was: 2.9.3)
> Password in clear in SSHD server's logs
> ---
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Assignee: Thomas Wolf
>Priority: Minor
> Fix For: 2.10.0
>
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the
> password of an SSH client authenticating to SSHD server is logged on SSHD
> server in "clear".
> This could result in a privacy/security issues at companies with strict
> security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 014e id=
> org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424}
> {color}{color:#242424}3 logMessage
> decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk
> #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e
> 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72
> 74 6e 65 72 31{color}{color:#242424}
> {color}{color:#242424}2{*}part1{*}ssh-connectionpassword.{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in
> logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1295) Connection attempt not canceled when a connection timeout occurs
[
https://issues.apache.org/jira/browse/SSHD-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1295:
--
Fix Version/s: 2.10.0
(was: 2.9.3)
> Connection attempt not canceled when a connection timeout occurs
>
>
> Key: SSHD-1295
> URL: https://issues.apache.org/jira/browse/SSHD-1295
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.10.0
>
>
> This is not a new bug; it's also present in earlier versions.
> When {{client.connect().verify(timeout)}} times out, the underlying
> asynchronous connection attempt still continues _and may still succeed_. If
> that happens, there is a connection and session that the user cannot use or
> close. (Short of calling verify().getSession() again, but that is a pattern I
> have never seen, and it also makes using a timeout rather useless.)
> This means that timeouts are inherently unreliable.
> Here's a simple test case illustrating this problem (for
> {{org.apache.sshd.client.ClientTest}}):
> {code:java}
> @Test
> public void testConnectTimeout() throws Exception {
> client.start();
> try {
> ConnectFuture future = client.connect(getCurrentTestName(),
> TEST_LOCALHOST, port);
> try {
> future.verify(1);
> fail("Timeout expected");
> } catch (InterruptedIOException | SshException e) {
> ClientSession session = null;
> try {
> session = future.verify(CONNECT_TIMEOUT).getSession();
> } catch (SshException e2) {
> assertTrue("Expected a timeout, got " + e2,
> e2.getMessage().contains("timeout"));
> }
> if (session != null) {
> assertTrue("Session should be closed", session.isClosed() ||
> session.isClosing());
> }
> }
> } finally {
> client.stop();
> }
> }
> {code}
> This test fails.
> When the {{ConnectFuture}} times out (or is canceled, or waiting is
> interrupted), the underlying {{IoConnectFuture}} must be canceled. If we do
> get an {{IoSession}} all the same, but the {{ConnectFuture}} is already
> canceled or timed out, the {{IoSession}} must be closed immediately.
> Preferrably before a {{Session}} is created at all; otherwise, that SSH
> session must be closed, too. Creating a {{ClientSession}} already starts the
> application-level protocol (sending the SSH ident, or if a proxy is used, the
> proxy connect request).
> The test also highlights another problem: there is no clear indication that
> the failure of {{verify()}} indicates a timeout. Probably there should be a
> dedicated exception for this, or at least the {{SshException}} should have a
> {{TimeoutException}} as cause.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1295) Connection attempt not canceled when a connection timeout occurs
[
https://issues.apache.org/jira/browse/SSHD-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1295.
---
Fix Version/s: 2.9.3
Assignee: Thomas Wolf
Resolution: Fixed
[Github PR 315|https://github.com/apache/mina-sshd/pull/315] has been merged.
> Connection attempt not canceled when a connection timeout occurs
>
>
> Key: SSHD-1295
> URL: https://issues.apache.org/jira/browse/SSHD-1295
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.3
>
>
> This is not a new bug; it's also present in earlier versions.
> When {{client.connect().verify(timeout)}} times out, the underlying
> asynchronous connection attempt still continues _and may still succeed_. If
> that happens, there is a connection and session that the user cannot use or
> close. (Short of calling verify().getSession() again, but that is a pattern I
> have never seen, and it also makes using a timeout rather useless.)
> This means that timeouts are inherently unreliable.
> Here's a simple test case illustrating this problem (for
> {{org.apache.sshd.client.ClientTest}}):
> {code:java}
> @Test
> public void testConnectTimeout() throws Exception {
> client.start();
> try {
> ConnectFuture future = client.connect(getCurrentTestName(),
> TEST_LOCALHOST, port);
> try {
> future.verify(1);
> fail("Timeout expected");
> } catch (InterruptedIOException | SshException e) {
> ClientSession session = null;
> try {
> session = future.verify(CONNECT_TIMEOUT).getSession();
> } catch (SshException e2) {
> assertTrue("Expected a timeout, got " + e2,
> e2.getMessage().contains("timeout"));
> }
> if (session != null) {
> assertTrue("Session should be closed", session.isClosed() ||
> session.isClosing());
> }
> }
> } finally {
> client.stop();
> }
> }
> {code}
> This test fails.
> When the {{ConnectFuture}} times out (or is canceled, or waiting is
> interrupted), the underlying {{IoConnectFuture}} must be canceled. If we do
> get an {{IoSession}} all the same, but the {{ConnectFuture}} is already
> canceled or timed out, the {{IoSession}} must be closed immediately.
> Preferrably before a {{Session}} is created at all; otherwise, that SSH
> session must be closed, too. Creating a {{ClientSession}} already starts the
> application-level protocol (sending the SSH ident, or if a proxy is used, the
> proxy connect request).
> The test also highlights another problem: there is no clear indication that
> the failure of {{verify()}} indicates a timeout. Probably there should be a
> dedicated exception for this, or at least the {{SshException}} should have a
> {{TimeoutException}} as cause.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1321) Cannot read ed25519 privatekey created using bouncy castle and eddsa-0.3.0.jar
[
https://issues.apache.org/jira/browse/SSHD-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1321.
---
Resolution: Duplicate
{quote}This needs to be immediately addressed. We are blocked because of this.
Please try to prioritize this.{quote}
Whoa. You're using an open-source library for free, and you don't have any
support agreement with us. (And we don't offer support contracts, either.)
There's no SLA, and no obligation to address anything immediately. So tone it
down a bit. The maintainers of this library are all volunteers doing this in
their free time.
Also, this is a duplicate of [Github issue
327|https://github.com/apache/mina-sshd/issues/327]. You're not getting faster
responses by posting this to multiple issue trackers. I'll close this one as a
duplicate.
For a resolution, see the Github issue. (If I had seen this "needs to be
immediately addressed" comment first, I would have been strongly tempted to
just let it lie for a few more weeks. It's just a coincidence that I did look
at this today.)
> Cannot read ed25519 privatekey created using bouncy castle and eddsa-0.3.0.jar
> --
>
> Key: SSHD-1321
> URL: https://issues.apache.org/jira/browse/SSHD-1321
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Pradyun Kumar
>Priority: Blocker
>
> We are trying to generate keypair using Ed25519 algorithm. We are using
> eddsa-0.3.0.jar.
> We have added the security provider for the same.
> Security.addProvider(new net.i2p.crypto.eddsa.EdDSASecurityProvider());
> Code snippet for key generation
> keypair = KeyUtils.generateKeyPair("ssh-ed25519", 256);
> Private key data is in this format:
> -BEGIN PRIVATE KEY-
> Proc-Type: 4,ENCRYPTED
> DEK-Info: AES-128-CBC,9014B6FD7912A84C144379D7E26FE20B
> iub1Uwel6zjsazQ5JIZqmCel/1HpxLyI2jcvO8ET9TF5w8ESCVMmlgPc6PAXgjdn
> 7N1bsn1lS/FOI4wv9nY90g==
> -END PRIVATE KEY-
> We are facing issue during the parsing of the key.
> rawData is a string which contains the private key data as shared above.
> passwordProvider is initialized below:
> FilePasswordProvider passwordProvider = new FilePasswordProvider() {
> public String getPassword(SessionContext session, NamedResource file, int
> index) throws IOException {
> return password;
> }
> };
> Below is the code snippet for parsing of the key:
> KeyPairResourceLoader bcLoader =
> SecurityUtils.getBouncycastleKeyPairResourceParser();
> Collection kpList = bcLoader.loadKeyPairs(null, null, passwordProvider,
> rawData);
> KeyPair p = GenericUtils.head(kpList);
> But loadKeyPairs method is returning an empty list.
> h3. Actual behavior
> loadKeyPairs is returning an empty list.
> h3. Expected behavior.
> loadKeyPairs should return the KeyPair list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1319) SftpRemotePathChannel.transferFrom(...) ignores position argument
[
https://issues.apache.org/jira/browse/SSHD-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1319.
---
Fix Version/s: 2.9.3
Resolution: Fixed
Thanks, Andreas!
> SftpRemotePathChannel.transferFrom(...) ignores position argument
> -
>
> Key: SSHD-1319
> URL: https://issues.apache.org/jira/browse/SSHD-1319
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Andreas Bergander
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.3
>
>
> The _position_ argument in the _SftpRemotePathChannel.transferFrom(...)_
> method seems only to be used when validating it and in debug logging.
> It should also affect where the data is written to the remote file. Perhaps
> it could be fixed with adding a call to
> {_}SftpOutputStreamAsync.setOffset(...){_}?
> {code:java}
> output.setOffset(position);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1319) SftpRemotePathChannel.transferFrom(...) ignores position argument
[
https://issues.apache.org/jira/browse/SSHD-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1319:
-
Assignee: Thomas Wolf
> SftpRemotePathChannel.transferFrom(...) ignores position argument
> -
>
> Key: SSHD-1319
> URL: https://issues.apache.org/jira/browse/SSHD-1319
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Andreas Bergander
>Assignee: Thomas Wolf
>Priority: Major
>
> The _position_ argument in the _SftpRemotePathChannel.transferFrom(...)_
> method seems only to be used when validating it and in debug logging.
> It should also affect where the data is written to the remote file. Perhaps
> it could be fixed with adding a call to
> {_}SftpOutputStreamAsync.setOffset(...){_}?
> {code:java}
> output.setOffset(position);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1319) SftpRemotePathChannel.transferFrom(...) ignores position argument
[
https://issues.apache.org/jira/browse/SSHD-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681453#comment-17681453
]
Thomas Wolf commented on SSHD-1319:
---
Actually that <= 0 condition is fine for {{transferFrom()}}. That method
returns the number of bytes written, and it provides no way of knowing whether
end-of-stream has been reached. One needs to know the expected number of bytes
to be transferred up front, and loop until that many bytes have been
transferred. So that bit is probably OK as is.
> SftpRemotePathChannel.transferFrom(...) ignores position argument
> -
>
> Key: SSHD-1319
> URL: https://issues.apache.org/jira/browse/SSHD-1319
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Andreas Bergander
>Priority: Major
>
> The _position_ argument in the _SftpRemotePathChannel.transferFrom(...)_
> method seems only to be used when validating it and in debug logging.
> It should also affect where the data is written to the remote file. Perhaps
> it could be fixed with adding a call to
> {_}SftpOutputStreamAsync.setOffset(...){_}?
> {code:java}
> output.setOffset(position);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1319) SftpRemotePathChannel.transferFrom(...) ignores position argument
[
https://issues.apache.org/jira/browse/SSHD-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680339#comment-17680339
]
Thomas Wolf commented on SSHD-1319:
---
Looks like this was an oversight in commit e85b67e0.
{{SftpOutputStreamAsync.setOffset()}} is not called anywhere... The version
before that did use that position parameter.
This also shows that there is a test missing that would exercise this
{{transferFrom()}} with a non-zero position.
Could you maybe provide a PR for a fix including a test on GitHub?
(BTW: the read loop in {{transferFrom()}} terminates when
{{ReadableByteChannel.read(Buffer) <= 0}}. But zero does not indicate
end-of-stream, only < 0 does.)
> SftpRemotePathChannel.transferFrom(...) ignores position argument
> -
>
> Key: SSHD-1319
> URL: https://issues.apache.org/jira/browse/SSHD-1319
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Andreas Bergander
>Priority: Major
>
> The _position_ argument in the _SftpRemotePathChannel.transferFrom(...)_
> method seems only to be used when validating it and in debug logging.
> It should also affect where the data is written to the remote file. Perhaps
> it could be fixed with adding a call to
> {_}SftpOutputStreamAsync.setOffset(...){_}?
> {code:java}
> output.setOffset(position);{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1318) Question about SSHD-1204
[
https://issues.apache.org/jira/browse/SSHD-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf closed SSHD-1318.
-
Assignee: Thomas Wolf
Resolution: Information Provided
> Question about SSHD-1204
>
>
> Key: SSHD-1318
> URL: https://issues.apache.org/jira/browse/SSHD-1318
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Assignee: Thomas Wolf
>Priority: Minor
>
> Hi Thomas,
> I have a SSHD client 2.8.0 connecting to a SFTP server which identifies
> itself with this banner *SSH-2.0-SFTP Server.*
> The SFTP client fails to authenticate with the following error:
> _Caused by: org.apache.sshd.common.SshException:
> DefaultAuthFuture[ssh-connection]: Failed (StreamCorruptedException) to
> execute: Incorrect identification (null characters not allowed) - at line 1
> character #1 after ''_
> This is the symptom described in SSHD-1204.
> The problem described in SSHD-1204 was solved with a workaround, i.e. setting
> {color:#242424}*org.apache.sshd.send-immediate-kex-init=false* for the SFTP
> client.{color}
>
> {color:#242424}Q. Do you think is safe setting
> {color:#242424}*org.apache.sshd.send-immediate-kex-init=false* for every SFTP
> client ; are you aware of any side effects ?{color}{color}
>
> {color:#242424}{color:#242424}{color:#242424}{color:#242424}Thank you in
> advance{color}{color}{color}{color}
> {color:#242424}{color:#242424}Kind Regards{color}{color}
>
> {color:#242424}{color:#242424}Roberto{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1316) Possible OOM in ChannelPipedInputStream
[ https://issues.apache.org/jira/browse/SSHD-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1316. --- Fix Version/s: 2.9.3 Assignee: Thomas Wolf Resolution: Fixed > Possible OOM in ChannelPipedInputStream > --- > > Key: SSHD-1316 > URL: https://issues.apache.org/jira/browse/SSHD-1316 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Evgeny Pasynkov >Assignee: Thomas Wolf >Priority: Major > Fix For: 2.9.3 > > > Hi, > Using Mina SSHD as a client, I sometimes experience the OutOfMemory in > ChannelPipedInputStream. The problem occurs when client reads data from > backing buffer slower than channel pushes data from socket into stream, so > the `ChannelPipedInputStream.buffer` grows beyond memory limits. > Could you please support limit for the backing buffer and throttle when it > overflows? > Thank you in advance -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1317) Finding default shell and its escape, quote characters
[
https://issues.apache.org/jira/browse/SSHD-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651414#comment-17651414
]
Thomas Wolf commented on SSHD-1317:
---
{quote}is it possible to find the followings by SSHD ?\{quote}
None that I know of. Perhaps examine the first prompt, and/or execute a first
command that tries to figure it out?
> Finding default shell and its escape, quote characters
> --
>
> Key: SSHD-1317
> URL: https://issues.apache.org/jira/browse/SSHD-1317
> Project: MINA SSHD
> Issue Type: Question
>Reporter: dgü
>Priority: Major
>
> Hello!
> I execute remote commands by exec channel. Arguments of the commands may
> include shell ({_}sh{_},{_}cmd{_},...) special characters(ie: _^_ for
> {_}cmd{_}). These special characters may work different on different shells.
> So, I must escape or quote them.
> is it possible to find the followings by SSHD ?
> * Default shell of SSH server
> * Escape character of shell
> * Quote character of shell
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1317) Finding default shell and its escape, quote characters
[
https://issues.apache.org/jira/browse/SSHD-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651414#comment-17651414
]
Thomas Wolf edited comment on SSHD-1317 at 12/22/22 8:26 PM:
-
{quote}is it possible to find the followings by SSHD ?{quote}
None that I know of. Perhaps examine the first prompt, and/or execute a first
command that tries to figure it out?
was (Author: wolft):
{quote}is it possible to find the followings by SSHD ?\{quote}
None that I know of. Perhaps examine the first prompt, and/or execute a first
command that tries to figure it out?
> Finding default shell and its escape, quote characters
> --
>
> Key: SSHD-1317
> URL: https://issues.apache.org/jira/browse/SSHD-1317
> Project: MINA SSHD
> Issue Type: Question
>Reporter: dgü
>Priority: Major
>
> Hello!
> I execute remote commands by exec channel. Arguments of the commands may
> include shell ({_}sh{_},{_}cmd{_},...) special characters(ie: _^_ for
> {_}cmd{_}). These special characters may work different on different shells.
> So, I must escape or quote them.
> is it possible to find the followings by SSHD ?
> * Default shell of SSH server
> * Escape character of shell
> * Quote character of shell
> Thanks in advance!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1318) Question about SSHD-1204
[
https://issues.apache.org/jira/browse/SSHD-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651365#comment-17651365
]
Thomas Wolf commented on SSHD-1318:
---
Did you verify with a packet trace that this is the same as SSHD-1204? IIRC,
the server sent in that case in one single message its KexInit followed by its
identification, when it should have been two messages, first the
identification, then the KexInit.
The only drawback of setting this flag I know of is that if you have a server
that somehow waits until it has received the client's KexInit, the connection
will stall since the client will be waiting for the server's KexInit first...
I wonder what implementation is used by this server...
> Question about SSHD-1204
>
>
> Key: SSHD-1318
> URL: https://issues.apache.org/jira/browse/SSHD-1318
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Priority: Minor
>
> Hi Thomas,
> I have a SSHD client 2.8.0 connecting to a SFTP server which identifies
> itself with this banner *SSH-2.0-SFTP Server.*
> The SFTP client fails to authenticate with the following error:
> _Caused by: org.apache.sshd.common.SshException:
> DefaultAuthFuture[ssh-connection]: Failed (StreamCorruptedException) to
> execute: Incorrect identification (null characters not allowed) - at line 1
> character #1 after ''_
> This is the symptom described in SSHD-1204.
> The problem described in SSHD-1204 was solved with a workaround, i.e. setting
> {color:#242424}*org.apache.sshd.send-immediate-kex-init=false* for the SFTP
> client.{color}
>
> {color:#242424}Q. Do you think is safe setting
> {color:#242424}*org.apache.sshd.send-immediate-kex-init=false* for every SFTP
> client ; are you aware of any side effects ?{color}{color}
>
> {color:#242424}{color:#242424}{color:#242424}{color:#242424}Thank you in
> advance{color}{color}{color}{color}
> {color:#242424}{color:#242424}Kind Regards{color}{color}
>
> {color:#242424}{color:#242424}Roberto{color}{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1316) Possible OOM in ChannelPipedInputStream
[ https://issues.apache.org/jira/browse/SSHD-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649802#comment-17649802 ] Thomas Wolf commented on SSHD-1316: --- Just yesterday I merged [PR-292|https://github.com/apache/mina-sshd/pull/292], which could be exactly this. Please try with current master. > Possible OOM in ChannelPipedInputStream > --- > > Key: SSHD-1316 > URL: https://issues.apache.org/jira/browse/SSHD-1316 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.2 >Reporter: Evgeny Pasynkov >Priority: Major > > Hi, > Using Mina SSHD as a client, I sometimes experience the OutOfMemory in > ChannelPipedInputStream. The problem occurs when client reads data from > backing buffer slower than channel pushes data from socket into stream, so > the `ChannelPipedInputStream.buffer` grows beyond memory limits. > Could you please support limit for the backing buffer and throttle when it > overflows? > Thank you in advance -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1315) Password in clear in SSHD server's logs
[
https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1315.
---
Fix Version/s: 2.9.3
Resolution: Fixed
PR merged.
> Password in clear in SSHD server's logs
> ---
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Assignee: Thomas Wolf
>Priority: Minor
> Fix For: 2.9.3
>
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the
> password of an SSH client authenticating to SSHD server is logged on SSHD
> server in "clear".
> This could result in a privacy/security issues at companies with strict
> security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 014e id=
> org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424}
> {color}{color:#242424}3 logMessage
> decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk
> #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e
> 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72
> 74 6e 65 72 31{color}{color:#242424}
> {color}{color:#242424}2{*}part1{*}ssh-connectionpassword.{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in
> logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1315) Password in clear in SSHD server's logs
[
https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1315:
-
Assignee: Thomas Wolf
> Password in clear in SSHD server's logs
> ---
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Assignee: Thomas Wolf
>Priority: Minor
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the
> password of an SSH client authenticating to SSHD server is logged on SSHD
> server in "clear".
> This could result in a privacy/security issues at companies with strict
> security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 014e id=
> org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424}
> {color}{color:#242424}3 logMessage
> decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk
> #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e
> 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72
> 74 6e 65 72 31{color}{color:#242424}
> {color}{color:#242424}2{*}part1{*}ssh-connectionpassword.{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in
> logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1315) Password in clear in SSHD server's logs
[
https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648262#comment-17648262
]
Thomas Wolf commented on SSHD-1315:
---
See [PR 289|https://github.com/apache/mina-sshd/pull/289].
> Password in clear in SSHD server's logs
> ---
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Assignee: Thomas Wolf
>Priority: Minor
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the
> password of an SSH client authenticating to SSHD server is logged on SSHD
> server in "clear".
> This could result in a privacy/security issues at companies with strict
> security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 014e id=
> org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424}
> {color}{color:#242424}3 logMessage
> decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk
> #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e
> 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72
> 74 6e 65 72 31{color}{color:#242424}
> {color}{color:#242424}2{*}part1{*}ssh-connectionpassword.{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in
> logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1315) Password in clear in SSHD server's logs
[
https://issues.apache.org/jira/browse/SSHD-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647705#comment-17647705
]
Thomas Wolf commented on SSHD-1315:
---
In the future please report security issues privately. Also if you're not sure
it actually is a security issue. See https://www.apache.org/security/ .
But since the cat is already out of the bag:
I can see that this may be problematic. Especially if there is some log
collector that keeps logs for posterity. So don't use trace/finest logging
level in production, and exclude trace level logging from log collectors if you
can.
Apparently nobody thought of this.
Fixing this will need careful analysis of (trace) logging statements. There is
more than the one location your example indicates; I already see at least three
more.
Obfuscating or blanking out the user names and passwords would require that the
buffer logging knows about the internal structure of certain SSH messages. I'd
rather not log these buffers at all, or log only a summary like "packet #7:
32... (contains log-in data)". For debugging purposes, one can still see that
it is an SSH message code 50, but not what it contains. Other log lines in the
vicinity will make it clear what authentication mechanism is used.
> Password in clear in SSHD server's logs
> ---
>
> Key: SSHD-1315
> URL: https://issues.apache.org/jira/browse/SSHD-1315
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.8.0
>Reporter: Roberto Deandrea
>Priority: Minor
>
> Hi Thomas,
> I noticed that setting SLF4J log level {*}org.apache.sshd.*=finest{*}, the
> password of an SSH client authenticating to SSHD server is logged on SSHD
> server in "clear".
> This could result in a privacy/security issues at companies with strict
> security rules.
>
> Evidence of this behavior is in the following trace :
> {color:#242424}[12/14/22 10:05:04:537 CET] 014e id=
> org.apache.sshd.common.util.logging.LoggingUtils{color}{color:#242424}
> {color}{color:#242424}3 logMessage
> decode({*}ServerSessionImpl{*}[null@/172.18.0.1:34845]) packet #7 [chunk
> #1](53/53) 32 00 00 00 05 70 61 72 74 31 00 00 00 0e 73 73 68 2d 63 6f 6e 6e
> 65 63 74 69 6f 6e 00 00 00 08 70 61 73 73 77 6f 72 64 00 00 00 00 08 70 61 72
> 74 6e 65 72 31{color}{color:#242424}
> {color}{color:#242424}2{*}part1{*}ssh-connectionpassword.{*}partner1{*}{color}
>
> Questions.
> 1. What do you think about this issue ?
> 2. Did you ever think about obfuscating in some ways "clear passwords" in
> logs?
> 3. Other considerations ?
>
> Than you for your collaboration.
> Kind Regards
> Roberto Deandrea
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (FTPSERVER-516) Bump Apache Mina Core from 2.1.6 to 2.2.1
[
https://issues.apache.org/jira/browse/FTPSERVER-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642804#comment-17642804
]
Thomas Wolf edited comment on FTPSERVER-516 at 12/3/22 9:23 AM:
{quote}how do I turn off this garbage Jira editor and get raw text?{quote}
By selecting "Code" from the "+" drop-down menu in the text editor, which
inserts {{\{code}}} mark-up. Which I did in you comment above now.
was (Author: wolft):
{quote}how do I turn off this garbage Jira editor and get raw text?\{quote}
By selecting "Code" from the "+" drop-down menu in the text editor, which
inserts {{\{code}}} mark-up.
> Bump Apache Mina Core from 2.1.6 to 2.2.1
> -
>
> Key: FTPSERVER-516
> URL: https://issues.apache.org/jira/browse/FTPSERVER-516
> Project: FtpServer
> Issue Type: Task
>Reporter: Gary D. Gregory
>Priority: Major
>
> Bump Apache Mina Core from 2.1.6 to 2.2.1: This is NOT a drop-in replacement
> as binary compatibility is broken. We do not compile with these errors:
> * DISABLE_ENCRYPTION_ONCE cannot be resolved or is not a field
> * The method getSslSession(FtpIoSession) is undefined for the type SslFilter
> * The type FtpIoSession must implement the inherited abstract method
> IoSession.isServer()
> Help needed.
> FWIW, there are likely a bunch of other binary compatibility issues just
> based on a quick comparison so more might pop up in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (FTPSERVER-516) Bump Apache Mina Core from 2.1.6 to 2.2.1
[
https://issues.apache.org/jira/browse/FTPSERVER-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642804#comment-17642804
]
Thomas Wolf commented on FTPSERVER-516:
---
{quote}how do I turn off this garbage Jira editor and get raw text?\{quote}
By selecting "Code" from the "+" drop-down menu in the text editor, which
inserts {{\{code}}} mark-up.
> Bump Apache Mina Core from 2.1.6 to 2.2.1
> -
>
> Key: FTPSERVER-516
> URL: https://issues.apache.org/jira/browse/FTPSERVER-516
> Project: FtpServer
> Issue Type: Task
>Reporter: Gary D. Gregory
>Priority: Major
>
> Bump Apache Mina Core from 2.1.6 to 2.2.1: This is NOT a drop-in replacement
> as binary compatibility is broken. We do not compile with these errors:
> * DISABLE_ENCRYPTION_ONCE cannot be resolved or is not a field
> * The method getSslSession(FtpIoSession) is undefined for the type SslFilter
> * The type FtpIoSession must implement the inherited abstract method
> IoSession.isServer()
> Help needed.
> FWIW, there are likely a bunch of other binary compatibility issues just
> based on a quick comparison so more might pop up in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (FTPSERVER-516) Bump Apache Mina Core from 2.1.6 to 2.2.1
[
https://issues.apache.org/jira/browse/FTPSERVER-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642193#comment-17642193
]
Thomas Wolf edited comment on FTPSERVER-516 at 12/3/22 9:20 AM:
Hi [~chrjohn]
I don't quite see how to re-implement
{{org.apache.ftpserver.impl.FtpIoSession.getClientCertificates()}} in terms of
the 2.2.x core.
Any ideas?
If did this locally:
{code:java}
public Certificate[] getClientCertificates() {
SslHandler sslHandler =
SslHandler.class.cast(getAttribute(SSL_HANDLER));
if (sslHandler != null) {
SSLSession sslSession = sslHandler.getEngine().getSession();
if (sslSession != null) {
try {
return sslSession.getPeerCertificates();
} catch (SSLPeerUnverifiedException e) {
// ignore, certificate will not be available to the session
}
}
}
// no certificates available
return null;
}
{code}
A... how do I turn off this garbage Jira editor and get raw text?
By adding SslHandler#getEngine().
Can't get the StartTlsFilter to work though.
was (Author: garydgregory):
Hi [~chrjohn]
I don't quite see how to re-implement
{{org.apache.ftpserver.impl.FtpIoSession.getClientCertificates()}} in terms of
the 2.2.x core.
Any ideas?
If did this locally:
public Certificate[] getClientCertificates() {
SslHandler sslHandler =
SslHandler.class.cast(getAttribute(SSL_HANDLER));
if (sslHandler != null) {
SSLSession sslSession = sslHandler.getEngine().getSession();
if (sslSession != null) {
try {
return sslSession.getPeerCertificates();
} catch (SSLPeerUnverifiedException e) {
// ignore, certificate will not be available to the session
}
}
}
// no certificates available
return null;
}
A... how do I turn off this garbage Jira editor and get raw text?
By adding SslHandler#getEngine().
Can't get the StartTlsFilter to work though.
> Bump Apache Mina Core from 2.1.6 to 2.2.1
> -
>
> Key: FTPSERVER-516
> URL: https://issues.apache.org/jira/browse/FTPSERVER-516
> Project: FtpServer
> Issue Type: Task
>Reporter: Gary D. Gregory
>Priority: Major
>
> Bump Apache Mina Core from 2.1.6 to 2.2.1: This is NOT a drop-in replacement
> as binary compatibility is broken. We do not compile with these errors:
> * DISABLE_ENCRYPTION_ONCE cannot be resolved or is not a field
> * The method getSslSession(FtpIoSession) is undefined for the type SslFilter
> * The type FtpIoSession must implement the inherited abstract method
> IoSession.isServer()
> Help needed.
> FWIW, there are likely a bunch of other binary compatibility issues just
> based on a quick comparison so more might pop up in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] (SSHD-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[ https://issues.apache.org/jira/browse/SSHD-1314 ]
Thomas Wolf deleted comment on SSHD-1314:
---
was (Author: wolft):
BTW, something unrelated: that {{OpenSSHKeyPairProvider}} in Karaf
de-serializes checking only the top-level class. AFAIK that is not sufficient
to guard against unsafe deserialization. Perhaps fix that, too.
> OpenSSHKeyPairProvider is not able to load SimpleKey
>
>
> Key: SSHD-1314
> URL: https://issues.apache.org/jira/browse/SSHD-1314
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jean-Baptiste Onofré
>Priority: Major
>
> Since this commit:
> {code:java}
> commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5
> Author: Thomas Wolf
> Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys
>
> Store host keys in the OpenSSH format. This makes it possible to use
> EdDSA host keys. Also set file permissions and read legacy files more
> carefully. .../AbstractGeneratorHostKeyProvider.java | 88
> ++---
> .../SimpleGeneratorHostKeyProvider.java | 109
> ++---
> .../SimpleGeneratorHostKeyProviderTest.java | 26 -
> 3 files changed, 194 insertions(+), 29 deletions(-)
> {code}
> it's not possible to "convert" a simple key to SSH key.
>
> Basically, the following code worked with sshd 2.9.1:
> {code:java}
> File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".priv");
> privateKeyTemp.deleteOnExit();
> File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".pub");
> publicKeyTemp.deleteOnExit();
> SimpleGeneratorHostKeyProvider simpleGenerator = new
> SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath());
> simpleGenerator.setKeySize(2048);
> simpleGenerator.setAlgorithm("DSA");
> List keys = simpleGenerator.loadKeys(null);
> KeyPair simpleKeyPair = keys.stream().findFirst().get();
> Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm());
> OpenSSHKeyPairProvider provider =
> new OpenSSHKeyPairProvider(privateKeyTemp.toPath(),
> publicKeyTemp.toPath(), "DSA", 2048, null);
> KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next();
> Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm());
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded());
> Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded());
> //also test that the original file has been replaced
> KeyPair keyPair =
> KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath()));
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded());
> {code}
> but it fails now with sshd 2.9.2 with:
> {code:java}
> INFO: generateKeyPair(DSA) generating host key - size=2048
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it 'directly'
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it as a legacy 'simple' key
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING:
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv
> is not a 'simple' key either
> {code}
> because we go on the last try in the {{loadkeys()}} method.
> I will work on a fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[
https://issues.apache.org/jira/browse/SSHD-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641520#comment-17641520
]
Thomas Wolf commented on SSHD-1314:
---
BTW, something unrelated: that {{OpenSSHKeyPairProvider}} in Karaf
de-serializes checking only the top-level class. AFAIK that is not sufficient
to guard against unsafe deserialization. Perhaps fix that, too.
> OpenSSHKeyPairProvider is not able to load SimpleKey
>
>
> Key: SSHD-1314
> URL: https://issues.apache.org/jira/browse/SSHD-1314
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jean-Baptiste Onofré
>Priority: Major
>
> Since this commit:
> {code:java}
> commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5
> Author: Thomas Wolf
> Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys
>
> Store host keys in the OpenSSH format. This makes it possible to use
> EdDSA host keys. Also set file permissions and read legacy files more
> carefully. .../AbstractGeneratorHostKeyProvider.java | 88
> ++---
> .../SimpleGeneratorHostKeyProvider.java | 109
> ++---
> .../SimpleGeneratorHostKeyProviderTest.java | 26 -
> 3 files changed, 194 insertions(+), 29 deletions(-)
> {code}
> it's not possible to "convert" a simple key to SSH key.
>
> Basically, the following code worked with sshd 2.9.1:
> {code:java}
> File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".priv");
> privateKeyTemp.deleteOnExit();
> File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".pub");
> publicKeyTemp.deleteOnExit();
> SimpleGeneratorHostKeyProvider simpleGenerator = new
> SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath());
> simpleGenerator.setKeySize(2048);
> simpleGenerator.setAlgorithm("DSA");
> List keys = simpleGenerator.loadKeys(null);
> KeyPair simpleKeyPair = keys.stream().findFirst().get();
> Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm());
> OpenSSHKeyPairProvider provider =
> new OpenSSHKeyPairProvider(privateKeyTemp.toPath(),
> publicKeyTemp.toPath(), "DSA", 2048, null);
> KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next();
> Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm());
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded());
> Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded());
> //also test that the original file has been replaced
> KeyPair keyPair =
> KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath()));
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded());
> {code}
> but it fails now with sshd 2.9.2 with:
> {code:java}
> INFO: generateKeyPair(DSA) generating host key - size=2048
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it 'directly'
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it as a legacy 'simple' key
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING:
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv
> is not a 'simple' key either
> {code}
> because we go on the last try in the {{loadkeys()}} method.
> I will work on a fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[
https://issues.apache.org/jira/browse/SSHD-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641501#comment-17641501
]
Thomas Wolf commented on SSHD-1314:
---
Using Java serialization to store a private key was a very bad idea to begin
with. The new code is backwards compatible: it can still load already stored
keys that use Java serialization that were produced by older versions of
{{SimpleGeneratorHostKeyProvider}}. (Unless some unknown security provider was
used, and its key classes are not whitelisted.) Only if there isn't a key yet
and a new key is written, a new format will be used that doesn't require Java
de-serialization for loading.
The upshot of this is that only code that makes assumptions about the storage
format used by {{SimpleGeneratorHostKeyProvider}}, such as that Karaf unit
test, will see a difference in behavior. Such code will have to be changed.
If the test is supposed to test that a key stored via Java serialization can be
loaded, then please see our {{SimpleGeneratorHostKeyProviderTest}} at [line
109|https://github.com/apache/mina-sshd/blob/master/sshd-common/src/test/java/org/apache/sshd/server/keyprovider/SimpleGeneratorHostKeyProviderTest.java#L109]:
don't rely on whatever {{SimpleGeneratorHostKeyProvider}} does but serialize
the key explicitly.
> OpenSSHKeyPairProvider is not able to load SimpleKey
>
>
> Key: SSHD-1314
> URL: https://issues.apache.org/jira/browse/SSHD-1314
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jean-Baptiste Onofré
>Priority: Major
>
> Since this commit:
> {code:java}
> commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5
> Author: Thomas Wolf
> Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys
>
> Store host keys in the OpenSSH format. This makes it possible to use
> EdDSA host keys. Also set file permissions and read legacy files more
> carefully. .../AbstractGeneratorHostKeyProvider.java | 88
> ++---
> .../SimpleGeneratorHostKeyProvider.java | 109
> ++---
> .../SimpleGeneratorHostKeyProviderTest.java | 26 -
> 3 files changed, 194 insertions(+), 29 deletions(-)
> {code}
> it's not possible to "convert" a simple key to SSH key.
>
> Basically, the following code worked with sshd 2.9.1:
> {code:java}
> File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".priv");
> privateKeyTemp.deleteOnExit();
> File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".pub");
> publicKeyTemp.deleteOnExit();
> SimpleGeneratorHostKeyProvider simpleGenerator = new
> SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath());
> simpleGenerator.setKeySize(2048);
> simpleGenerator.setAlgorithm("DSA");
> List keys = simpleGenerator.loadKeys(null);
> KeyPair simpleKeyPair = keys.stream().findFirst().get();
> Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm());
> OpenSSHKeyPairProvider provider =
> new OpenSSHKeyPairProvider(privateKeyTemp.toPath(),
> publicKeyTemp.toPath(), "DSA", 2048, null);
> KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next();
> Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm());
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded());
> Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded());
> //also test that the original file has been replaced
> KeyPair keyPair =
> KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath()));
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded());
> {code}
> but it fails now with sshd 2.9.2 with:
> {code:java}
> INFO: generateKeyPair(DSA) generating host key - size=2048
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it 'directly'
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it as a legacy 'simple' key
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING:
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv
> is not a 'simple' key either
> {code}
> because we go on the last try in the {{loadkeys()}} method.
> I will work on a fix.
--
This
[jira] [Comment Edited] (SSHD-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[
https://issues.apache.org/jira/browse/SSHD-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641472#comment-17641472
]
Thomas Wolf edited comment on SSHD-1314 at 11/30/22 6:35 PM:
-
I must be missing something fundamentally. What is
{{{}OpenSSHKeyPairProvider{}}}?? There is no such class in Apache MINA SSHD.
(Edit) This seems to be a class in Karaf. So why do you file an issue against
SSHD? Anyway, you might be interested in [PR
278|https://github.com/apache/mina-sshd/pull/278]. Seems to me that the Karaf
class could also use {{SecurityUtils}}, and if that fails, try to de-serialize
the key. I don't know Karaf, so I may be missing some context: why can't Karaf
simply let the {{SimpleGeneratorHostKeyProvider}} load the key?
was (Author: wolft):
I must be missing something fundamentally. What is
{{{}OpenSSHKeyPairProvider{}}}?? There is no such class in Apache MINA SSHD.
> OpenSSHKeyPairProvider is not able to load SimpleKey
>
>
> Key: SSHD-1314
> URL: https://issues.apache.org/jira/browse/SSHD-1314
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jean-Baptiste Onofré
>Priority: Major
>
> Since this commit:
> {code:java}
> commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5
> Author: Thomas Wolf
> Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys
>
> Store host keys in the OpenSSH format. This makes it possible to use
> EdDSA host keys. Also set file permissions and read legacy files more
> carefully. .../AbstractGeneratorHostKeyProvider.java | 88
> ++---
> .../SimpleGeneratorHostKeyProvider.java | 109
> ++---
> .../SimpleGeneratorHostKeyProviderTest.java | 26 -
> 3 files changed, 194 insertions(+), 29 deletions(-)
> {code}
> it's not possible to "convert" a simple key to SSH key.
>
> Basically, the following code worked with sshd 2.9.1:
> {code:java}
> File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".priv");
> privateKeyTemp.deleteOnExit();
> File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".pub");
> publicKeyTemp.deleteOnExit();
> SimpleGeneratorHostKeyProvider simpleGenerator = new
> SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath());
> simpleGenerator.setKeySize(2048);
> simpleGenerator.setAlgorithm("DSA");
> List keys = simpleGenerator.loadKeys(null);
> KeyPair simpleKeyPair = keys.stream().findFirst().get();
> Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm());
> OpenSSHKeyPairProvider provider =
> new OpenSSHKeyPairProvider(privateKeyTemp.toPath(),
> publicKeyTemp.toPath(), "DSA", 2048, null);
> KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next();
> Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm());
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded());
> Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded());
> //also test that the original file has been replaced
> KeyPair keyPair =
> KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath()));
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded());
> {code}
> but it fails now with sshd 2.9.2 with:
> {code:java}
> INFO: generateKeyPair(DSA) generating host key - size=2048
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it 'directly'
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it as a legacy 'simple' key
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING:
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv
> is not a 'simple' key either
> {code}
> because we go on the last try in the {{loadkeys()}} method.
> I will work on a fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1314) OpenSSHKeyPairProvider is not able to load SimpleKey
[
https://issues.apache.org/jira/browse/SSHD-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641472#comment-17641472
]
Thomas Wolf commented on SSHD-1314:
---
I must be missing something fundamentally. What is
{{{}OpenSSHKeyPairProvider{}}}?? There is no such class in Apache MINA SSHD.
> OpenSSHKeyPairProvider is not able to load SimpleKey
>
>
> Key: SSHD-1314
> URL: https://issues.apache.org/jira/browse/SSHD-1314
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jean-Baptiste Onofré
>Priority: Major
>
> Since this commit:
> {code:java}
> commit 5a8fe830b2a2308a2b24ac8115a391af477f64f5
> Author: Thomas Wolf
> Date: Sat Nov 5 21:00:40 2022 +0100 Better file handling for host keys
>
> Store host keys in the OpenSSH format. This makes it possible to use
> EdDSA host keys. Also set file permissions and read legacy files more
> carefully. .../AbstractGeneratorHostKeyProvider.java | 88
> ++---
> .../SimpleGeneratorHostKeyProvider.java | 109
> ++---
> .../SimpleGeneratorHostKeyProviderTest.java | 26 -
> 3 files changed, 194 insertions(+), 29 deletions(-)
> {code}
> it's not possible to "convert" a simple key to SSH key.
>
> Basically, the following code worked with sshd 2.9.1:
> {code:java}
> File privateKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".priv");
> privateKeyTemp.deleteOnExit();
> File publicKeyTemp = File.createTempFile(this.getClass().getCanonicalName(),
> ".pub");
> publicKeyTemp.deleteOnExit();
> SimpleGeneratorHostKeyProvider simpleGenerator = new
> SimpleGeneratorHostKeyProvider(privateKeyTemp.toPath());
> simpleGenerator.setKeySize(2048);
> simpleGenerator.setAlgorithm("DSA");
> List keys = simpleGenerator.loadKeys(null);
> KeyPair simpleKeyPair = keys.stream().findFirst().get();
> Assert.assertEquals("DSA", simpleKeyPair.getPrivate().getAlgorithm());
> OpenSSHKeyPairProvider provider =
> new OpenSSHKeyPairProvider(privateKeyTemp.toPath(),
> publicKeyTemp.toPath(), "DSA", 2048, null);
> KeyPair convertedKeyPair = provider.loadKeys(null).iterator().next();
> Assert.assertEquals("DSA", convertedKeyPair.getPrivate().getAlgorithm());
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),convertedKeyPair.getPrivate().getEncoded());
> Assert.assertArrayEquals(simpleKeyPair.getPublic().getEncoded(),convertedKeyPair.getPublic().getEncoded());
> //also test that the original file has been replaced
> KeyPair keyPair =
> KeyPairLoader.getKeyPair(Files.newInputStream(privateKeyTemp.toPath()));
> Assert.assertArrayEquals(simpleKeyPair.getPrivate().getEncoded(),keyPair.getPrivate().getEncoded());
> {code}
> but it fails now with sshd 2.9.2 with:
> {code:java}
> INFO: generateKeyPair(DSA) generating host key - size=2048
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it 'directly'
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING: Failed to parse keypair in
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv.
> Attempting to parse it as a legacy 'simple' key
> Nov 30, 2022 6:12:35 PM
> org.apache.karaf.shell.ssh.keygenerator.OpenSSHKeyPairProvider loadKeys
> WARNING:
> /tmp/org.apache.karaf.shell.ssh.keygenerator.OpenSSHGeneratorKeyFileProviderTest8057592323787152069.priv
> is not a 'simple' key either
> {code}
> because we go on the last try in the {{loadkeys()}} method.
> I will work on a fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637979#comment-17637979
]
Thomas Wolf commented on SSHD-1307:
---
Sorry for having missed that. Yes, it is. 2.9.2 was released a few days ago. It
does include this fix.
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
> immediately
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) closing
> socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected oshut
> local=/127.0.0.1:9000 remote=/127.0.0.1:62027]
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
>
[jira] [Commented] (SSHD-1312) using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes
[ https://issues.apache.org/jira/browse/SSHD-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632509#comment-17632509 ] Thomas Wolf commented on SSHD-1312: --- I don't understand. It's a server-side property. It sets a limit on how much data the server returns at most for one read request. If it is set in the client, it has no effect. A client may get a full 64kB when it requests 64kB if the server is configured with a higher limit. > using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes > -- > > Key: SSHD-1312 > URL: https://issues.apache.org/jira/browse/SSHD-1312 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 >Reporter: p2 >Priority: Major > > Hi Team, > I'm using this api: > org.apache.sshd.sftp.client.SftpClient#read(org.apache.sshd.sftp.client.SftpClient.Handle, > long, byte[]) > my code is : > byte[] buff = new byte[65536]; > readLen = sftp.read(handle, 0, buff)) > my file length is bigger than 65536, > but the readLen result is 64512, > I want to know what would affect the read length. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1312) using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes
[
https://issues.apache.org/jira/browse/SSHD-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631121#comment-17631121
]
Thomas Wolf commented on SSHD-1312:
---
It's configured on the server side. If you want your client to work with all
kinds of servers, you cannot rely on any particular value. In Apache MINA sshd,
it can be configured via {{SftpModuleProperties.MAX_READDATA_PACKET_LENGTH}}.
The default value of 63kB is what you were seeing. It is a bit low; we are
considering increasing it in a future version.
> using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes
> --
>
> Key: SSHD-1312
> URL: https://issues.apache.org/jira/browse/SSHD-1312
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.8.0
>Reporter: p2
>Priority: Major
>
> Hi Team,
> I'm using this api:
> org.apache.sshd.sftp.client.SftpClient#read(org.apache.sshd.sftp.client.SftpClient.Handle,
> long, byte[])
> my code is :
> byte[] buff = new byte[65536];
> readLen = sftp.read(handle, 0, buff))
> my file length is bigger than 65536,
> but the readLen result is 64512,
> I want to know what would affect the read length.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1312) using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes
[ https://issues.apache.org/jira/browse/SSHD-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631093#comment-17631093 ] Thomas Wolf commented on SSHD-1312: --- A server is allowed to return less data than requested. Keep reading until it returns -1 (EOF reached). > using org.apache.sshd.sftp.client.SftpClient#read the Number of read bytes > -- > > Key: SSHD-1312 > URL: https://issues.apache.org/jira/browse/SSHD-1312 > Project: MINA SSHD > Issue Type: Question >Affects Versions: 2.8.0 >Reporter: p2 >Priority: Major > > Hi Team, > I'm using this api: > org.apache.sshd.sftp.client.SftpClient#read(org.apache.sshd.sftp.client.SftpClient.Handle, > long, byte[]) > my code is : > byte[] buff = new byte[65536]; > readLen = sftp.read(handle, 0, buff)) > my file length is bigger than 65536, > but the readLen result is 64512, > I want to know what would affect the read length. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1311) Do you have any timeline for the 2.9.2 release?
[ https://issues.apache.org/jira/browse/SSHD-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1311. --- Resolution: Information Provided No. We're working on it. > Do you have any timeline for the 2.9.2 release? > > > Key: SSHD-1311 > URL: https://issues.apache.org/jira/browse/SSHD-1311 > Project: MINA SSHD > Issue Type: Question >Reporter: Tilden >Priority: Major > > Do you have any timeline for the 2.9.2 release? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1309) SSH Jumphost with User and password Auth
[ https://issues.apache.org/jira/browse/SSHD-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf resolved SSHD-1309. --- Resolution: Information Provided > SSH Jumphost with User and password Auth > > > Key: SSHD-1309 > URL: https://issues.apache.org/jira/browse/SSHD-1309 > Project: MINA SSHD > Issue Type: Question >Reporter: Tilden >Priority: Major > > Can you please provide documentation/example how to use SSH SSH Jumphost with > User and password Auth? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1310) SftpFileSystem.close() method, closes the session as well.
[
https://issues.apache.org/jira/browse/SSHD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629378#comment-17629378
]
Thomas Wolf commented on SSHD-1310:
---
The {{SftpFileSystem}} is intended to be used with a session, not with a
channel.
> SftpFileSystem.close() method, closes the session as well.
> ---
>
> Key: SSHD-1310
> URL: https://issues.apache.org/jira/browse/SSHD-1310
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Tilden
>Priority: Major
>
> SftpFileSystem.close() method, closes the session as well.
> We expect only the sftpfilesystem channel to be closed. Since we use the
> same session for multiple operations (exec command, SFTP download & upload,
> SFTP client list directory).
>
> SftpFileSystem.java
> public void close() throws IOException {
> if (this.isOpen()) {
> SftpFileSystemProvider provider = this.provider();
> String fsId = this.getId();
> SftpFileSystem fs = provider.removeFileSystem(fsId);
> ClientSession session = this.getClientSession();
> *session.close(true);*
> if (fs != null && fs != this) {
> throw new FileSystemException(fsId, fsId, "Mismatched FS
> instance for id=" + fsId);
> }
> }
> }
>
>
> can you please check and let us know, if this can be fixed ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1309) SSH Jumphost with User and password Auth
[
https://issues.apache.org/jira/browse/SSHD-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627268#comment-17627268
]
Thomas Wolf commented on SSHD-1309:
---
Install a {{UserInteraction}} with {{resolveAuthPasswordAttempt()}} overridden
to ask the user. (Or to return an appropriate pre-determined password depending
on the session or session's remote address.)
> SSH Jumphost with User and password Auth
>
>
> Key: SSHD-1309
> URL: https://issues.apache.org/jira/browse/SSHD-1309
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Tilden
>Priority: Major
>
> Can you please provide documentation/example how to use SSH SSH Jumphost with
> User and password Auth?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1287) Use the maximum packet size of the communication partner
[
https://issues.apache.org/jira/browse/SSHD-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1287.
---
Fix Version/s: 2.9.2
Resolution: Fixed
The bugs are fixed:
* Use _remote_ window packet size for default write buffer size
* Correctly transfer data if read buffer size > twice the server's maximum
response limit
(The server's maximum response limit is defined by
{{{}SftpModuleProperties.MAX_READDATA_PACKET_LENGTH{}}}.)
The following enhancements mentioned in comments are deferred to later changes:
* Increasing that server-side limit (default is currently 63kB).
* Client-side: make use of {{lim...@openssh.com}} information to set buffer
sizes.
> Use the maximum packet size of the communication partner
>
>
> Key: SSHD-1287
> URL: https://issues.apache.org/jira/browse/SSHD-1287
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Thomas Wolf
>Priority: Minor
> Fix For: 2.9.2
>
> Attachments: ClientMain.java, ConsoleLog, ServerMain.java
>
>
> It appears that SSHD may use the maximum packet size presented by the
> communicating party to request reception.
> RFC 4254 contains the following statement, where "maximum packet size" can be
> read as "the maximum packet size that the sender is willing to accept" (as in
> "initial window size").
> {code:java}
> Section 5.1 Opening a Channel
> The 'maximum packet size' specifies the maximum size of
> 2an individual data packet that can be sent to the sender.{code}
> The client/server must comply with its own declared maximum packet size.
>
> I encountered this issue when I was using "freeSSHd" as an SFTP server.
> The version of freeSSHd is 1.3.1.
> The event is confirmed by creating a server with SSHD.
> Attached are the client and server sources, as well as the client debug logs
> (up to the first read request).
> When communicating with these, the client knows that its maximum packet size
> is "32768" and the server's maximum packet size is "65536".
> {code:java}
> // client window
> [main] DEBUG org.apache.sshd.common.channel.Window -
> init(Window[client/local](SftpChannelSubsystem[id=0,
> recipient=-1]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp]))
> size=2097152, max=2097152, packet=32768
> // server window
> [sshd-SshClient[5702b3b1]-nio2-thread-3] DEBUG
> org.apache.sshd.common.channel.Window -
> init(Window[client/remote](SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[user@localhost/127.0.0.1:10022][sftp]))
> size=2097152, max=2097152, packet=65536 {code}
> And when requesting to receive a file, it requests to read 65536 bytes at a
> time. This means that it attempts to receive packets that exceed 32768 bytes.
> {code:java}
> [main] TRACE org.apache.sshd.sftp.client.impl.SftpInputStreamAsync -
> sendRequests(SftpInputStreamAsync[ClientSessionImpl[user@localhost/127.0.0.1:10022]][/data4M.txt])
> enqueue pending ack: SftpAckData[id=103, offset=0, length=65536] {code}
>
> I hope this report is helpful.
> I am doing machine translation, so please allow it to be unnatural.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1173:
--
Issue Type: Bug (was: Question)
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Thomas Wolf
>Priority: Critical
> Labels: SFTP, mina, sshd
> Fix For: 2.9.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17625229#comment-17625229
]
Thomas Wolf commented on SSHD-1307:
---
Not really. I have one more fix to get in, but then I could ask our release
manager to cut a 2.9.2. (There have been basically only bug fixes since 2.9.1,
so a 2.10.0 feels a bit early.) If all goes well, it should be possible to get
that out in November. But since we're all volunteers I can't promise anything.
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
> immediately
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) closing
[jira] [Commented] (SSHD-1308) No exception is thrown if setting environment variable is ignored by SSH server
[
https://issues.apache.org/jira/browse/SSHD-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17623373#comment-17623373
]
Thomas Wolf commented on SSHD-1308:
---
{quote}client application must be notified by a message such as _setting
environment variable is not allowed_ instead of success.
{quote}
That's not part of the SSH RFC's. As I wrote, you'd have to program that
yourself. And in fact, there are SSH clients that do expect the "silently
ignore" behavior (for instance, git using SSH for cloning or fetching).
Most SSH servers restrict the environment variables that can be set via the SSH
"env" channel command anyway. It depends on the server configuration; see
[AcceptEnv|https://man.openbsd.org/sshd_config#AcceptEnv] in the OpenSSH server
configuration.
If you want the "throw an exception" behavior, here's one approach how you
could implement this in your client: with enough overriding and custom
subclassing, you could implement a custom {{ChannelExec}} that would send the
"env" channel requests with {{{}want-reply = true{}}}. A correct server must
send back an {{SSH_MSG_CHANNEL_FAILURE}} if it doesn't set an environment
variable. You would also need a queue (per channel) of sent "env" requests
without reply yet, and fulfill the OpenFuture only once all requests have been
positively acknowledged. If any of them receives a failure reply, close the
channel and fulfill the OpenFuture with an exception.
But implementing this correctly is not easy.
In the Apache MINA sshd library we will not do this. We follow the OpenSSH
behavior here, which is to send the "env" requests with {{{}want-reply =
false{}}}. Which means the client silently ignores the fact that the server may
not have set an environment variable.
A well-designed application protocol between the command you invoke on the
server and your client can recognize and deal with both cases, whether or not
the server set the environment variable. Again, git is such an example.
Your work-around of using {{sh -c}} and setting the variables inside the
command is valid, and much easier than implementing the "throw exception"
behavior.
> No exception is thrown if setting environment variable is ignored by SSH
> server
> ---
>
> Key: SSHD-1308
> URL: https://issues.apache.org/jira/browse/SSHD-1308
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Priority: Major
>
> Hello!
> If an environment variable set by
> _org.apache.sshd.client.session.ClientSession#createExecChannel(command,null,env)_
> is ignored by SSH server and exit code returns 0, then this may cause
> unexpected behaviour in client application.
> For example, client application may do different tasks when an environment
> variable is set and not set. In both cases, client application may return 0.
> Client application may assume that it worked successfully. But, indeed its
> environment variable is ignored and worked as if environment variable is not
> set.
> is it possible throw an exception if setting environment variable is ignored
> by SSH server ?
> Thanks in advance...
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1307.
---
Fix Version/s: 2.9.2
Resolution: Fixed
PR merged.
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
> immediately
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) closing
> socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected oshut
> local=/127.0.0.1:9000 remote=/127.0.0.1:62027]
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
[jira] [Commented] (SSHD-1308) No exception is thrown if setting environment variable is ignored by SSH server
[
https://issues.apache.org/jira/browse/SSHD-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17623011#comment-17623011
]
Thomas Wolf commented on SSHD-1308:
---
Like OpenSSH, Apache MINA sshd sends the channel requests for setting
environment variables with {{{}want-reply = false{}}}.
You could implement this yourself, but it'd be quite involved. Better figure
some other way to pass data to the server-side command, for instance via
command arguments.
> No exception is thrown if setting environment variable is ignored by SSH
> server
> ---
>
> Key: SSHD-1308
> URL: https://issues.apache.org/jira/browse/SSHD-1308
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Priority: Major
>
> Hello!
> If an environment variable set by
> _org.apache.sshd.client.session.ClientSession#createExecChannel(command,null,env)_
> is ignored by SSH server and exit code returns 0, then this may cause
> unexpected behaviour in client application.
> For example, client application may do different tasks when an environment
> variable is set and not set. In both cases, client application may return 0.
> Client application may assume that it worked successfully. But, indeed its
> environment variable is ignored and worked as if environment variable is not
> set.
> is it possible throw an exception if setting environment variable is ignored
> by SSH server ?
> Thanks in advance...
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1302) Reading again from exhausted ChannelExec#getInvertedOut() throws IOException instead of returning -1
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1302.
---
Fix Version/s: 2.9.2
Resolution: Fixed
Merged the PR.
> Reading again from exhausted ChannelExec#getInvertedOut() throws IOException
> instead of returning -1
>
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Minor
> Fix For: 2.9.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622698#comment-17622698
]
Thomas Wolf commented on SSHD-1307:
---
[PR 257|https://github.com/apache/mina-sshd/pull/257] should fix this.
[~alexander.ama...@oracle.com]: if you'd like to try this out before it gets
merged, you could either pull that PR from GitHub (using
{{{}refs/pull/257/head{}}}, e.g. {{{}git fetch origin
refs/pull/257/head:refs/remotes/origin/pr-257{}}}, then check out the remote
branch {{origin/pr-257}} in your clone), or fetch and check out the
{{sshd-1307}} branch from my fork (also on GitHub, linked at the top of the
PR), or get a [ZIP with all
files|https://github.com/tomaswolf/mina-sshd/archive/refs/heads/sshd-1307.zip]
from GitHub.
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Split out from
> [SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
>
[jira] [Updated] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1307:
--
Description:
Split out from
[SSHD-1055|https://issues.apache.org/jira/browse/SSHD-1055?focusedCommentId=17621354=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17621354]:
I am currently experiencing an exception that appears to be related to the use
of the serverSession.shudownOutputStream(); in the TcpIpClientChannel.handleEOF
method.
My context is the following
* Apache Mina sshd client version 2.9.1 on the local side.
* OpenSSH 5.9 on the remote server side.
* Local port forwarding port 9000 to remote localhost:8080
* The error occurs on the Apache Mina sshd client side.
I intermittently take exceptions on URL connections that are completed and they
have received the last of the data and is processing the SSH_MSG_CHANNEL_EOF
Any ideas or thoughts would be appreciated.
{code:java}
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=999
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 999 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=2
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 2 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=115
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 115 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleEof(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_EOF
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
shudownOutputStream(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes at
write cycle=17 afer 987500 nanos: null
09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
caught ClosedChannelException[null] - calling handler
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
IoSession now
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
immediately
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
doCloseImmediately(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
closing socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected oshut
local=/127.0.0.1:9000 remote=/127.0.0.1:62027]
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
doCloseImmediately(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[closed] closed
09:16:42.880 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Acceptor - unmapSession(id=168):
Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]
09:16:42.880 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.forward.DefaultForwarder -
sessionClosed(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
closing channel=TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22] after
67 messages - cause=ClosedChannelException
09:16:42.880 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
[jira] [Commented] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
[
https://issues.apache.org/jira/browse/SSHD-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622690#comment-17622690
]
Thomas Wolf commented on SSHD-1307:
---
Apache MINA sshd is still trying to send data received via the tunnel to
whatever is connected to port 9000 on thread #6. This happens asynchronously.
But before that data was written completely, the channel already got the EOF
and then shut down the output on thread #8. Hence #6 gets the
{{{}ClosedChannelException{}}}.
That's an oversight. The MINA and Netty transport back-ends actually queue a
shutdown request on their write queue, so this doesn't happen for them. We'll
have to do the same for the NIO2 transport.
> Nio2Session.shutdownOutput() should wait for writes in progress
> ---
>
> Key: SSHD-1307
> URL: https://issues.apache.org/jira/browse/SSHD-1307
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Thomas Wolf
>Assignee: Thomas Wolf
>Priority: Major
>
> Split out from SSHD-1055:
> I am currently experiencing an exception that appears to be related to the
> use of the serverSession.shudownOutputStream(); in the
> TcpIpClientChannel.handleEOF method.
> My context is the following
> * Apache Mina sshd client version 2.9.1 on the local side.
> * OpenSSH 5.9 on the remote server side.
> * Local port forwarding port 9000 to remote localhost:8080
> * The error occurs on the Apache Mina sshd client side.
> I intermittently take exceptions on URL connections that are completed and
> they have received the last of the data and is processing the
> SSH_MSG_CHANNEL_EOF
> Any ideas or thoughts would be appreciated.
> {code:java}
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=999
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 999 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=2
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 2 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleData(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_DATA len=115
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> writing 115 bytes
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.forward.TcpipClientChannel -
> handleEof(TcpipClientChannel[id=71,
> recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
> SSH_MSG_CHANNEL_EOF
> 09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> shudownOutputStream(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027])
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes
> at write cycle=17 afer 987500 nanos: null
> 09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
> caught ClosedChannelException[null] - calling handler
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
> IoSession now
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
> immediately
> 09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> doCloseImmediately(Nio2Session[local=/127.0.0.1:9000,
> remote=/127.0.0.1:62027]) closing
>
[jira] [Commented] (SSHD-1055) Remote port forwarding mode does not handle EOF properly
[
https://issues.apache.org/jira/browse/SSHD-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622689#comment-17622689
]
Thomas Wolf commented on SSHD-1055:
---
Though perhaps I was mistaken with my quick analysis. Thread #8 does the
{{{}shutdownOutputStream(){}}}, but thread #6 gets the exception. I missed that
on my first look.
So it's unlikely that commit
[277563e26|https://github.com/apache/mina-sshd/commit/277563e26] fixed this.
I've opened SSHD-1307 for this. Let's continue the discussion there.
> Remote port forwarding mode does not handle EOF properly
>
>
> Key: SSHD-1055
> URL: https://issues.apache.org/jira/browse/SSHD-1055
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.0
>
> Attachments: image001.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I want to call the remote server's gRPC service locally through an SSH
> tunnel.
> MyApp -> MINA SSHD -> \{Internet} -> gRPC Server
> It works just fine with OpenSSH, but there is a small problem(no problems
> with core functions, only in unusual circumstances) with Mina SSHD.
> I think the problem is Mina SSHD's handling of EOF.
> Here is the example:
> Step 1. Start a gRPC server:
> Because we only need a gRPC server to reproduce the problem, so I write a
> simple version without any service:
> {code:java}
>
> io.grpc
> grpc-netty-shaded
> 1.27.2
>
>
> io.grpc
> grpc-protobuf
> 1.27.2
>
>
> io.grpc
> grpc-stub
> 1.27.2
>
> {code}
> main:
> {code:java}
> import io.grpc.Server;
> import io.grpc.ServerBuilder;
> public class EmptyGrpcServer {
> public static void main(String[] args) throws Exception {
> Server server = ServerBuilder.forPort(23645).build().start();
> server.awaitTermination();
> }
> }
> {code}
> Full example can be fond here:
> [https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/helloworld/HelloWorldServer.java]
>
> Step 2. Start a MINA SSHD server:
> {code:java}
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.nio.file.Paths;
> public class Example1 {
> public static void main(String[] args) throws Exception {
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/a.ser")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1000);
> }
> }
> {code}
> Step 3. Create a channel using ssh client
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -vvv -p 12133 -f -x -N -T -R
> 0.0.0.0:0:127.0.0.1:23645 test5@127.0.0.1
> {code}
> Step 4. Reproduce
> If I connect directly to the gRPC server using curl, cause gRPC using http/2,
> I would get error output like this:
> {code:java}
> $ curl 127.0.0.1:23645
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> Then if I do step 3 with an OpenSSH server, I would get same error output:
> {code:java}
> $ ssh -o 'ExitOnForwardFailure yes' -f -x -N -T -R 0.0.0.0:0:127.0.0.1:23645
> w...@dev.kbyte.cn
> Allocated port 13525 for remote forward to 127.0.0.1:23645
> $
> $ curl dev.kbyte.cn:13525
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> But when I do step 3 with MINA SSHD, curl would stuck without any output:
> {code:java}
> $ curl 127.0.0.1:55604
> {code}
> I found MINA SSHD had already got and wrote the package with the string
> "Unexpected.HTTP/1.x.request:.GET", and received SSH_MSG_CHANNEL_EOF.
> So I think handleEof should do more? like send SSH_MSG_CHANNEL_EOF to curl?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1307) Nio2Session.shutdownOutput() should wait for writes in progress
Thomas Wolf created SSHD-1307:
-
Summary: Nio2Session.shutdownOutput() should wait for writes in
progress
Key: SSHD-1307
URL: https://issues.apache.org/jira/browse/SSHD-1307
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Thomas Wolf
Assignee: Thomas Wolf
Split out from SSHD-1055:
I am currently experiencing an exception that appears to be related to the use
of the serverSession.shudownOutputStream(); in the TcpIpClientChannel.handleEOF
method.
My context is the following
* Apache Mina sshd client version 2.9.1 on the local side.
* OpenSSH 5.9 on the remote server side.
* Local port forwarding port 9000 to remote localhost:8080
* The error occurs on the Apache Mina sshd client side.
I intermittently take exceptions on URL connections that are completed and they
have received the last of the data and is processing the SSH_MSG_CHANNEL_EOF
Any ideas or thoughts would be appreciated.
{code:java}
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=999
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 999 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=2
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 2 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleData(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_DATA len=115
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
writeBuffer(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
writing 115 bytes
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.forward.TcpipClientChannel -
handleEof(TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22])
SSH_MSG_CHANNEL_EOF
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
shudownOutputStream(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes at
write cycle=17 afer 987500 nanos: null
09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
exceptionCaught(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
caught ClosedChannelException[null] - calling handler
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleReadCycleCompletion(Nio2Session[local=/127.0.0.1:9000,
remote=/127.0.0.1:62027]) Socket has been disconnected (result=-1), closing
IoSession now
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
close(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]) Closing
immediately
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
doCloseImmediately(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
closing socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[connected oshut
local=/127.0.0.1:9000 remote=/127.0.0.1:62027]
09:16:42.879 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
doCloseImmediately(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
socket=sun.nio.ch.WindowsAsynchronousSocketChannelImpl[closed] closed
09:16:42.880 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.io.nio2.Nio2Acceptor - unmapSession(id=168):
Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027]
09:16:42.880 [sshd-SshClient[477424ca]-nio2-thread-4] DEBUG
org.apache.sshd.common.forward.DefaultForwarder -
sessionClosed(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
closing channel=TcpipClientChannel[id=71,
recipient=2]-ClientSessionImpl[r...@elib17.us.oracle.com/10.80.104.97:22] after
67 messages - cause=ClosedChannelException
09:16:42.880
[jira] [Commented] (SSHD-1055) Remote port forwarding mode does not handle EOF properly
[
https://issues.apache.org/jira/browse/SSHD-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622672#comment-17622672
]
Thomas Wolf commented on SSHD-1055:
---
Yes. It's also available on GitHub: [https://github.com/apache/mina-sshd].
> Remote port forwarding mode does not handle EOF properly
>
>
> Key: SSHD-1055
> URL: https://issues.apache.org/jira/browse/SSHD-1055
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.0
>
> Attachments: image001.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I want to call the remote server's gRPC service locally through an SSH
> tunnel.
> MyApp -> MINA SSHD -> \{Internet} -> gRPC Server
> It works just fine with OpenSSH, but there is a small problem(no problems
> with core functions, only in unusual circumstances) with Mina SSHD.
> I think the problem is Mina SSHD's handling of EOF.
> Here is the example:
> Step 1. Start a gRPC server:
> Because we only need a gRPC server to reproduce the problem, so I write a
> simple version without any service:
> {code:java}
>
> io.grpc
> grpc-netty-shaded
> 1.27.2
>
>
> io.grpc
> grpc-protobuf
> 1.27.2
>
>
> io.grpc
> grpc-stub
> 1.27.2
>
> {code}
> main:
> {code:java}
> import io.grpc.Server;
> import io.grpc.ServerBuilder;
> public class EmptyGrpcServer {
> public static void main(String[] args) throws Exception {
> Server server = ServerBuilder.forPort(23645).build().start();
> server.awaitTermination();
> }
> }
> {code}
> Full example can be fond here:
> [https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/helloworld/HelloWorldServer.java]
>
> Step 2. Start a MINA SSHD server:
> {code:java}
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.nio.file.Paths;
> public class Example1 {
> public static void main(String[] args) throws Exception {
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/a.ser")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1000);
> }
> }
> {code}
> Step 3. Create a channel using ssh client
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -vvv -p 12133 -f -x -N -T -R
> 0.0.0.0:0:127.0.0.1:23645 test5@127.0.0.1
> {code}
> Step 4. Reproduce
> If I connect directly to the gRPC server using curl, cause gRPC using http/2,
> I would get error output like this:
> {code:java}
> $ curl 127.0.0.1:23645
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> Then if I do step 3 with an OpenSSH server, I would get same error output:
> {code:java}
> $ ssh -o 'ExitOnForwardFailure yes' -f -x -N -T -R 0.0.0.0:0:127.0.0.1:23645
> w...@dev.kbyte.cn
> Allocated port 13525 for remote forward to 127.0.0.1:23645
> $
> $ curl dev.kbyte.cn:13525
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> But when I do step 3 with MINA SSHD, curl would stuck without any output:
> {code:java}
> $ curl 127.0.0.1:55604
> {code}
> I found MINA SSHD had already got and wrote the package with the string
> "Unexpected.HTTP/1.x.request:.GET", and received SSH_MSG_CHANNEL_EOF.
> So I think handleEof should do more? like send SSH_MSG_CHANNEL_EOF to curl?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1055) Remote port forwarding mode does not handle EOF properly
[
https://issues.apache.org/jira/browse/SSHD-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622629#comment-17622629
]
Thomas Wolf commented on SSHD-1055:
---
[~alexander.ama...@oracle.com] :
I suspect the real problem is not the exception backtrace at 09:16:42.883. That
one appears to be a follow-up error of an earlier problem:
{code:java}
09:16:42.873 [sshd-SshClient[477424ca]-nio2-thread-8] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
shudownOutputStream(Nio2Session[local=/127.0.0.1:9000, remote=/127.0.0.1:62027])
09:16:42.875 [sshd-SshClient[477424ca]-nio2-thread-6] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleWriteCycleFailure(Nio2Session[local=/127.0.0.1:9000,
remote=/127.0.0.1:62027]) failed (ClosedChannelException) to write 115 bytes at
write cycle=17 afer 987500 nanos: null
{code}
(The log message at 09:16:42.875 has a typo :-/ )
Apparently {{shutdownOutputStream()}} got a {{{}ClosedChannelException{}}}.
This looks suspiciously like the problem fixed in commit
[277563e26|https://github.com/apache/mina-sshd/commit/277563e26]. Can you try
running with current master and see if the problem still occurs?
> Remote port forwarding mode does not handle EOF properly
>
>
> Key: SSHD-1055
> URL: https://issues.apache.org/jira/browse/SSHD-1055
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Feng Jiajie
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.0
>
> Attachments: image001.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I want to call the remote server's gRPC service locally through an SSH
> tunnel.
> MyApp -> MINA SSHD -> \{Internet} -> gRPC Server
> It works just fine with OpenSSH, but there is a small problem(no problems
> with core functions, only in unusual circumstances) with Mina SSHD.
> I think the problem is Mina SSHD's handling of EOF.
> Here is the example:
> Step 1. Start a gRPC server:
> Because we only need a gRPC server to reproduce the problem, so I write a
> simple version without any service:
> {code:java}
>
> io.grpc
> grpc-netty-shaded
> 1.27.2
>
>
> io.grpc
> grpc-protobuf
> 1.27.2
>
>
> io.grpc
> grpc-stub
> 1.27.2
>
> {code}
> main:
> {code:java}
> import io.grpc.Server;
> import io.grpc.ServerBuilder;
> public class EmptyGrpcServer {
> public static void main(String[] args) throws Exception {
> Server server = ServerBuilder.forPort(23645).build().start();
> server.awaitTermination();
> }
> }
> {code}
> Full example can be fond here:
> [https://github.com/grpc/grpc-java/blob/master/examples/src/main/java/io/grpc/examples/helloworld/HelloWorldServer.java]
>
> Step 2. Start a MINA SSHD server:
> {code:java}
> import org.apache.sshd.server.SshServer;
> import org.apache.sshd.server.forward.AcceptAllForwardingFilter;
> import org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider;
> import java.nio.file.Paths;
> public class Example1 {
> public static void main(String[] args) throws Exception {
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(12133);
> sshd.setKeyPairProvider(new
> SimpleGeneratorHostKeyProvider(Paths.get("/tmp/a.ser")));
> sshd.setPasswordAuthenticator((username, password, session) -> true);
> sshd.setForwardingFilter(AcceptAllForwardingFilter.INSTANCE);
> sshd.start();
> Thread.sleep(1000);
> }
> }
> {code}
> Step 3. Create a channel using ssh client
> {code:java}
> ssh -o 'ExitOnForwardFailure yes' -vvv -p 12133 -f -x -N -T -R
> 0.0.0.0:0:127.0.0.1:23645 test5@127.0.0.1
> {code}
> Step 4. Reproduce
> If I connect directly to the gRPC server using curl, cause gRPC using http/2,
> I would get error output like this:
> {code:java}
> $ curl 127.0.0.1:23645
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> Then if I do step 3 with an OpenSSH server, I would get same error output:
> {code:java}
> $ ssh -o 'ExitOnForwardFailure yes' -f -x -N -T -R 0.0.0.0:0:127.0.0.1:23645
> w...@dev.kbyte.cn
> Allocated port 13525 for remote forward to 127.0.0.1:23645
> $
> $ curl dev.kbyte.cn:13525
> ���+Unexpected HTTP/1.x request: GET /
> $
> {code}
> But when I do step 3 with MINA SSHD, curl would stuck without any output:
> {code:java}
> $ curl 127.0.0.1:55604
> {code}
> I found MINA SSHD had already got and wrote the package with the string
> "Unexpected.HTTP/1.x.request:.GET", and received SSH_MSG_CHANNEL_EOF.
> So I think handleEof should do more? like send SSH_MSG_CHANNEL_EOF to curl?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail:
[jira] [Updated] (SSHD-1302) Reading again from exhausted ChannelExec#getInvertedOut() throws IOException instead of returning -1
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1302:
--
Priority: Minor (was: Major)
> Reading again from exhausted ChannelExec#getInvertedOut() throws IOException
> instead of returning -1
>
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1303:
--
Issue Type: Bug (was: Improvement)
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1302) Reading again from exhausted ChannelExec#getInvertedOut() throws IOException instead of returning -1
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1302:
--
Summary: Reading again from exhausted ChannelExec#getInvertedOut() throws
IOException instead of returning -1 (was: Handling empty
ChannelExec#getInvertedOut() to rely on InputStream)
> Reading again from exhausted ChannelExec#getInvertedOut() throws IOException
> instead of returning -1
>
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1302) Handling empty ChannelExec#getInvertedOut() to rely on InputStream
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf updated SSHD-1302:
--
Issue Type: Bug (was: Improvement)
> Handling empty ChannelExec#getInvertedOut() to rely on InputStream
> --
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1302) Handling empty ChannelExec#getInvertedOut() to rely on InputStream
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622470#comment-17622470
]
Thomas Wolf commented on SSHD-1302:
---
Thanks for this report. IMO this is simply broken, and should be considered a
bug. Fixed by [PR 256|https://github.com/apache/mina-sshd/pull/256].
> Handling empty ChannelExec#getInvertedOut() to rely on InputStream
> --
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1302) Handling empty ChannelExec#getInvertedOut() to rely on InputStream
[
https://issues.apache.org/jira/browse/SSHD-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1302:
-
Assignee: Thomas Wolf
> Handling empty ChannelExec#getInvertedOut() to rely on InputStream
> --
>
> Key: SSHD-1302
> URL: https://issues.apache.org/jira/browse/SSHD-1302
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
>
> Hello!
> If I read an input stream until end of it, and then read it again, it throws
> an exception.
> Here is the test case:
> {code:java}
> BufferedReader input;
> String line;
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getInputStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389){quote}
> It looks the input stream is closed.
> is it possible not to throw an exception to rely on java.io.InputStream ?
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1303.
---
Fix Version/s: 2.9.2
Resolution: Fixed
PR merged.
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1303:
-
Assignee: Thomas Wolf
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Assignee: Thomas Wolf
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1303) Keeping error streams and input streams separate after ChannelExec#setRedirectErrorStream(true) is called
[
https://issues.apache.org/jira/browse/SSHD-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17621381#comment-17621381
]
Thomas Wolf commented on SSHD-1303:
---
Makes sense. See [PR 255|https://github.com/apache/mina-sshd/pull/255].
> Keeping error streams and input streams separate after
> ChannelExec#setRedirectErrorStream(true) is called
> -
>
> Key: SSHD-1303
> URL: https://issues.apache.org/jira/browse/SSHD-1303
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.9.1
> Environment: Java 8
>Reporter: dgü
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello!
> As I understand, if I call {_}ChannelExec#setRedirectErrorStream(true){_},
> then _ChannelExec#getInvertedErr()_ and _ChannelExec#getInvertedOut()_ return
> the same input stream.
> If I redirect error stream and read the error stream before the input stream,
> then the error stream returns the message even if there is an error or not,
> which is not expected.
> Here is the test case
> {code:java}
> BufferedReader input;
> String line;
>
> //process.getErrorStream() gets its value from
> ChannelExec#getInvertedErr()
> System.out.println("getErrorStream: " + process.getErrorStream());
> input = new BufferedReader(new
> InputStreamReader(process.getErrorStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> //process.getInputStream() gets its value from
> ChannelExec#getInvertedOut()
> System.out.println("getInputStream: " + process.getInputStream());
> input = new BufferedReader(new
> InputStreamReader(process.getInputStream()));
> while ((line = input.readLine()) != null) {
> System.out.println(line);
> }
> {code}
> Here is an output excerpt:
> {quote}getErrorStream:
> org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> total 0
> drwx--. 3 root root 17 Oct 17 10:31
> systemd-private-c3ce924f90c24e4a86f637831f434fe3-chronyd.service-DwM2fR
> drwx--. 3 root root 17 Oct 14 13:22
> systemd-private-e0701fd845894b6087a236a976c00b35-chronyd.service-2z3OOv
> getInputStream: org.apache.sshd.common.channel.ChannelPipedInputStream@bd8db5a
> Exception in thread "main" java.io.IOException: Pipe closed after 0 cycles
> at
> org.apache.sshd.common.channel.ChannelPipedInputStream.read(ChannelPipedInputStream.java:126)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> {quote}
> As seen above, _ls_ command output comes from the error stream even if the
> error redirection is set to _true_ and command runs {_}successfully{_}.
> The second problem is an exception problem. It is independent from the error
> stream redirection. I have openned SSHD-1302 for this.
> Requests:
> - Is it possible to make ChannelExec#getInvertedErr() and
> ChannelExec#getInvertedOut() two separate input streams ?
> - Is it possible to rely on java.lang.ProcessBuilder, so that the stream
> returned from error stream will always be a _null input stream_ as below from
> Java 8 source code:
> static class NullInputStream extends InputStream {
> static final NullInputStream INSTANCE = new NullInputStream();
> private NullInputStream() {}
> public int read() \{ return -1; }
> public int available()
> { return 0; }
> }
> Thanks in advance...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1256) PortForwardingTest.testRemoteForwardingSecondTimeInSameSession sometimes fails in Github CI
[ https://issues.apache.org/jira/browse/SSHD-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Wolf updated SSHD-1256: -- Labels: upstream-issue (was: ) > PortForwardingTest.testRemoteForwardingSecondTimeInSameSession sometimes > fails in Github CI > --- > > Key: SSHD-1256 > URL: https://issues.apache.org/jira/browse/SSHD-1256 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Thomas Wolf >Priority: Major > Labels: upstream-issue > > Cannot reproduce locally. A timing issue? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf resolved SSHD-1173.
---
Fix Version/s: 2.9.2
Resolution: Fixed
Merged [PR 251|https://github.com/apache/mina-sshd/pull/251].
Took a while to get this to pass the CI builds. The change itself turned out to
be sound, but it uncovered some other problems that were not easy to track down.
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Thomas Wolf
>Priority: Critical
> Labels: SFTP, mina, sshd
> Fix For: 2.9.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Wolf reassigned SSHD-1173:
-
Assignee: Thomas Wolf
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Assignee: Thomas Wolf
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17614681#comment-17614681
]
Thomas Wolf commented on SSHD-1173:
---
{quote}If the client session is forcibly closed (I used 2 mins) for being idle
it will still deadlock the main thread{quote}
With what version of Apache MINA sshd? Do you have sample code?
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17614680#comment-17614680
]
Thomas Wolf commented on SSHD-1173:
---
{quote}Try explaining the above to a customer will be nightmarish.{quote}
Why? "There was an interoperability problem between Apache MINA sshd and some
other SSH implementations. We fixed the problem by setting a configuration
option in Apache MINA sshd."
{quote}I strongly urge you to reconsider keeping this option.{quote}
Why should we keep an option that produces wrong behavior? No. [PR
251|https://github.com/apache/mina-sshd/pull/251] removes the options, and
makes Apache MINA sshd always behave as if they were {{true}}. The explanation
for the customer then becomes "There was a bug in Apache MINA sshd that caused
interoperability problems with some SSH implementations. We fixed the problem
by upgrading the Apache MINA sshd version to one in which this bug was fixed."
I tried to explain what the change does in the
[CHANGES|https://github.com/apache/mina-sshd/blob/9010fa7e09642c7a3d3481d673b2025ce7391f57/CHANGES.md#channel-windows].
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17614146#comment-17614146
]
Thomas Wolf commented on SSHD-1173:
---
[PR 251|https://github.com/apache/mina-sshd/pull/251] does away with this flag
altogether.
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> is called without any timeout, which then defaults to LONG.MAX here: at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43),
> shouldn't we have configurable timeout here? or what's the point of default
> timeout? what are we really waiting for in at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1173) SFTP worker threads got stuck while processing PUT methods against one specific SFTP server
[
https://issues.apache.org/jira/browse/SSHD-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613908#comment-17613908
]
Thomas Wolf commented on SSHD-1173:
---
Great find! Going back to [RFC 4254, section
5.2|https://www.rfc-editor.org/rfc/rfc4254#section-5.2], I see nothing in the
specification that would say _when_ a party has to send a
SSH_MSG_CHANNEL_WINDOW_ADJUST message.
OpenSSH does so when half the window has been consumed. But apparently there
are implementations that do so only when the window has been fully consumed.
SSHD-1123 sums it up nicely: if we have more data than the remaining window
size and then don't send any data, not consuming window space, and the peer
will sent a window adjustment only if more window space is consumed, then the
channel gets stuck and both parties will wait on each other.
Seems to me that {{CHUNK_IF_WINDOW_LESS_THAN_PACKET = false}} just leads to a
broken implementation, and that option should be removed. Always send data,
unless the window size is zero.
Also see the [first erratum on RFC
4254|https://www.rfc-editor.org/errata/rfc4254] (which has status "verified"):
if that is true, the length computations done should include the length field
(+4). The current implementation only considers the actual length of the data.
So perhaps we should wait for a window adjustment if the window size is < 4.
> SFTP worker threads got stuck while processing PUT methods against one
> specific SFTP server
> ---
>
> Key: SSHD-1173
> URL: https://issues.apache.org/jira/browse/SSHD-1173
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.6.0
>Reporter: Pavel Pohner
>Priority: Critical
> Labels: SFTP, mina, sshd
>
> Hey guys,
> Recently I've encountered one remote SFTP server, that causes SFTP worker
> threads to enter TIMED_WAITING state, from which they do not recover. Please,
> take a look into this thread dump:
> {code:java}
> SFTP-worker-3 #2155 prio=5 os_prio=0 cpu=61692.09ms elapsed=1136151.86s
> tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000]SFTP-worker-3" #2155 prio=5 os_prio=0 cpu=61692.09ms
> elapsed=1136151.86s tid=0x7fe41c005800 nid=0x18808 in Object.wait()
> [0x7fe145b1d000] java.lang.Thread.State: TIMED_WAITING (on object
> monitor) at java.lang.Object.wait(java.base@11.0.10/Native Method) - waiting
> on at
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java:69)
> - waiting to re-lock in wait() <0x0006e3bbc420> (a
> org.apache.sshd.common.channel.IoWriteFutureImpl) at
> org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:109)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:39)
> at
> org.apache.sshd.common.io.AbstractIoWriteFuture.verify(AbstractIoWriteFuture.java:30)
> at
> org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
> at
> org.apache.sshd.sftp.client.impl.DefaultSftpClient.send(DefaultSftpClient.java:292)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.flush(SftpOutputStreamAsync.java:210)
> at
> org.apache.sshd.sftp.client.impl.SftpOutputStreamAsync.write(SftpOutputStreamAsync.java:141)
> at java.io.InputStream.transferTo(java.base@11.0.10/InputStream.java:705) at
> com.mina.command.Put.replyInto(Put.java:55) at
> com.sftpserver.MinaSftpHandler.channelReadInternal(MinaSftpHandler.java:251)
> at
> com.sftpserver.MinaSftpHandler.lambda$channelRead$0(MinaSftpHandler.java:125)
> at com.sftpserver.MinaSftpHandler$$Lambda$392/0x000800764040.run(Unknown
> Source) at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.10/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.10/FutureTask.java:264) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
> {code}
> Seems like the thread is waiting for lock in
> org.apache.sshd.common.future.DefaultSshFuture.await0(DefaultSshFuture.java),
> I'm currently not sure what thread holds the lock and why it's not ever
> released.
> Also, I'm not able to reproduce this, but it constantly happens to all the
> PUT methods targeting one specific remote server (which I don't own), so I
> suppose there would be something odd with the remote server, but it doesn't
> mean, that we shouldn't be able to deal with that.
> Have you ever seen such behavior? Could it be Mina sshd's bug? (seems like
> verify() in
>
