[GitHub] [mina-sshd] Thrameos commented on pull request #314: Report exceptions in logs
Thrameos commented on PR #314: URL: https://github.com/apache/mina-sshd/pull/314#issuecomment-1397660577 For reference here is the log with this code being exercised. ``` 2023/01/19 13:52:38,097 [sshd-SftpSubsystem-61352-thread-1] DEBUG SftpSubsystem - doRealPath(ServerSessionImpl[test@/127.0.0.1:51365])[id=1] SSH_FXP_REALPATH (path=.) 2023/01/19 13:52:38,187 [sshd-SftpSubsystem-61352-thread-1] DEBUG SftpSubsystem - doSendStatus[ServerSessionImpl[test@/127.0.0.1:51365]][id=1,cmd=16] exception java.lang.RuntimeException at org.testing.MyFileSystem.getSeparator(MyFileSystem.java:68) at org.apache.sshd.common.util.SelectorUtils.translateToLocalFileSystemPath(SelectorUtils.java:545) at org.apache.sshd.sftp.server.SftpFileSystemAccessor.resolveLocalFilePath(SftpFileSystemAccessor.java:113) at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.resolveFile(AbstractSftpSubsystemHelper.java:3029) at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.doRealPath(AbstractSftpSubsystemHelper.java:1444) at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:392) at org.apache.sshd.sftp.server.SftpSubsystem.doProcess(SftpSubsystem.java:327) at org.apache.sshd.sftp.server.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:344) at org.apache.sshd.sftp.server.SftpSubsystem.run(SftpSubsystem.java:303) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at java.base/java.lang.Thread.run(Thread.java:832) 2023/01/19 13:52:38,191 [sshd-SftpSubsystem-61352-thread-1] DEBUG SftpSubsystem - doSendStatus(ServerSessionImpl[test@/127.0.0.1:51365])[id=1] SSH_FXP_STATUS (substatus=SSH_FX_FAILURE, lang=, msg=General failure) ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Thrameos commented on a diff in pull request #314: Report exceptions in logs
Thrameos commented on code in PR #314:
URL: https://github.com/apache/mina-sshd/pull/314#discussion_r1081905234
##
sshd-sftp/src/main/java/org/apache/sshd/sftp/server/AbstractSftpSubsystemHelper.java:
##
@@ -338,6 +338,9 @@ protected void process(Buffer buffer) throws IOException {
if (type == SftpConstants.SSH_FXP_INIT) {
throw e;
}
+if (log.isDebugEnabled()) {
+log.debug("process({}) Exception", session, e);
+}
Review Comment:
The method name will get lost.As it should be on the stack trace it
should be okay.I made the change, please review.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #315: Cancellation and time-outs of futures
tomaswolf opened a new pull request, #315: URL: https://github.com/apache/mina-sshd/pull/315 Implement cancellation of futures such that cancelling a user-visible future also cancels the underlying internal operation. Since cancellations can be asynchronous, introduce the concept of a `CancelFuture` that can be used to wait until a cancellation has indeed been effected. Augment `Future.verify()` with additional optional `CancelOption` parameters so that client code can specify whether a time-out should cancel the future and its underlying operation. In particular, `DefaultConnectFuture.verify()` now by default does cancel the connection attempt on a time-out. This avoids leaking a socket if the low-level connection attempt succeeds after the high-level time-out has expired. Add a property to control a possibly connection time-out that might exist at the I/O library level. Add tests for connection time-outs and for cancelling a connection attempt, and verify that either no sessions are created, or if so, that they are being closed or already have been closed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #308: GH-302: Fail writes after SSH session is closed
tomaswolf merged PR #308: URL: https://github.com/apache/mina-sshd/pull/308 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
tomaswolf closed issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100% URL: https://github.com/apache/mina-sshd/issues/302 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on a diff in pull request #314: Report exceptions in logs
tomaswolf commented on code in PR #314:
URL: https://github.com/apache/mina-sshd/pull/314#discussion_r1081679988
##
sshd-sftp/src/main/java/org/apache/sshd/sftp/server/AbstractSftpSubsystemHelper.java:
##
@@ -338,6 +338,9 @@ protected void process(Buffer buffer) throws IOException {
if (type == SftpConstants.SSH_FXP_INIT) {
throw e;
}
+if (log.isDebugEnabled()) {
+log.debug("process({}) Exception", session, e);
+}
Review Comment:
Why don't you do this _inside_ `sendStatus(Buffer buffer, int id, Throwable
e, int cmd, Object... args)`? There would be only a single place to change. The
exception stack trace that would be logged would identify where it occurred.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Thrameos commented on issue #313: SftpSubsystem eats exceptions
Thrameos commented on issue #313: URL: https://github.com/apache/mina-sshd/issues/313#issuecomment-1397427750 I gave it a shot. I am not sure what information is needed to identify the source. I put the session and the id assuming that it matches the other calls. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Thrameos opened a new pull request, #314: Report exceptions in logs
Thrameos opened a new pull request, #314: URL: https://github.com/apache/mina-sshd/pull/314 Fixes #313 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #313: SftpSubsystem eats exceptions
tomaswolf commented on issue #313: URL: https://github.com/apache/mina-sshd/issues/313#issuecomment-1396564724 There is debug logging in [sendStatus()](https://github.com/apache/mina-sshd/blob/b19a3ed0bfe9b933463307278db5632ab2602b70/sshd-sftp/src/main/java/org/apache/sshd/sftp/server/AbstractSftpSubsystemHelper.java#L2955), but it's true that it doesn't log the exception itself or its stack trace. Additional logging in the first variant (with the Throwable parameter) might be good indeed. Do you want to provide a PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] MiniTaT commented on issue #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作
MiniTaT commented on issue #312: URL: https://github.com/apache/mina-sshd/issues/312#issuecomment-1396385975 > We can't go to the customer site to check, so we'll contact the customer to try "netsh winsock reset"。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Thrameos opened a new issue, #313: SftpSubsystem eats exceptions
Thrameos opened a new issue, #313:
URL: https://github.com/apache/mina-sshd/issues/313
### Version
2.9.3
### Bug description
While trying to implement a virtual file system for SFTPD, I ran into a
condition in which the connection would close but there was nothing in the
logs. After 5 hours of trying to configure the logger all I could see is
DEBUG messages, but no log of the exception or error. I eventually traced it
down that although there is a master catch in SftpSubsystem.run, it was never
being reached.It appears that AbstractSftpSubsystemHelper contains a lot of
code with this sort of pattern...
```
} catch (IOException | RuntimeException e) {
sendStatus(prepareReply(buffer), id, e,
SftpConstants.SSH_FXP_OPEN, path);
return;
}
```
It seems like poor practice to not log something when an exception occurs.
To reproduce this I implemented a custom FileSystemFactory which returned
MyFileSystem in which getSeparator() throw an exception. To hit multiple
points I had to proxy Path, FileSystem, and FileSystemProvider to the normal
versions. The exception must happen in the Path, FileSystem, or
FileSystemProvider. Throws in FileSystemFactory are caught properly as
SftpSubsystem catches during prepare, but not in doProcess.
### Actual behavior
Nothing was logged.
### Expected behavior
A log message with the source of the exception. If this is addressed,
perhaps this should be logged at the DEBUG level as this was not normally
logged in the past. After all there are a lot of tolerable exceptions
(missing file, permissions, etc) that are not errors for normal operation.
### Relevant log output
_No response_
### Other information
Logging was configured with log4j with DEBUG to console. But the lack of
output is programmatic rather than the logger, so it should be universal.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作
tomaswolf commented on issue #312: URL: https://github.com/apache/mina-sshd/issues/312#issuecomment-1387539730 You could also try using a later Java version. Try Java 11 or 17, or maybe even 19. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作
tomaswolf commented on issue #312:
URL: https://github.com/apache/mina-sshd/issues/312#issuecomment-1385419758
The error message appears to indicate that this is Windows error 10038 ("An
operation was attempted on something that is not a socket."). Searching the
Internet for "OS 10038" or related things (like the Chinese error message
text!) gets quite a few hits. Some include the Apache HTTP server; compare the
[mod_winnt configuration of Apache httpd
2.2](https://httpd.apache.org/docs/2.2/mod/mpm_winnt.html#win32disableacceptex).
(In newer releases, that config was removed; compare the [httpd 2.4
documentation](https://httpd.apache.org/docs/current/mod/mpm_winnt.html): it
appears the problem is still there, but httpd falls back to another API if
there are too many failures.)
The cause appears to be unclear. Most hits report this occurring suddenly
from time to time in otherwise working applications. It's being mentioned for
many different applications. Some mention it was some corruption in the Windows
TCP/IP stack, and some people claim running "netsh winsock reset" would resolve
this problem.
It is possible that the AsynchronousSocketChannel used by the Apache MINA
sshd NIO2 transport back-end exercises some Windows code that triggers a bug in
Windows. The Java native code does use the Windows ConnectEx function... maybe
that can have the same problem as AcceptEx mentioned on other sites. JSch
definitely doesn't use AsynchronousSocketChannel.
You could try using the sshd-mina or sshd-netty transport back-ends with
Apache MINA sshd; those also do not use AsynchronousSocketChannel.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] MiniTaT commented on issue #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作
MiniTaT commented on issue #312: URL: https://github.com/apache/mina-sshd/issues/312#issuecomment-1385163955  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] MiniTaT opened a new issue, #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作
MiniTaT opened a new issue, #312: URL: https://github.com/apache/mina-sshd/issues/312 ### Version 2.9.2 ### Bug description Recently, we switched from jsch to mina ssh. In some of our customers' environments, we encountered the following error when connecting to the customer's machine through SSH. When we roll back to the version using jsch, we can connect the environment properly. Operating system: windows server 2016 target environment ip: IPv6 ### Actual behavior connection build failed. ### Expected behavior Connect the device properly. ### Relevant log output ```Shell  Caused by: java.io.IOException: 在一个非套接字上尝试了一个操作。 at sun.nio.ch.WindowsAsynchronousSocketChannelImpl.connect0(Native Method) ~[?:1.8.0_332] at sun.nio.ch.WindowsAsynchronousSocketChannelImpl.access$200(WindowsAsynchronousSocketChannelImpl.java:43) ~[?:1.8.0_332] at sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ConnectTask.run(WindowsAsynchronousSocketChannelImpl.java:235) ~[?:1.8.0_332] at sun.nio.ch.WindowsAsynchronousSocketChannelImpl.implConnect(WindowsAsynchronousSocketChannelImpl.java:382) ~[?:1.8.0_332] at sun.nio.ch.AsynchronousSocketChannelImpl.connect(AsynchronousSocketChannelImpl.java:210) ~[?:1.8.0_332] at org.apache.sshd.common.io.nio2.Nio2Connector.connect(Nio2Connector.java:72) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.SshClient.doConnect(SshClient.java:632) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.SshClient.doConnect(SshClient.java:615) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.SshClient.connect(SshClient.java:546) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.SshClient.connect(SshClient.java:538) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.session.ClientSessionCreator.connect(ClientSessionCreator.java:74) ~[sshd-core-2.9.2.jar:2.9.2] at org.apache.sshd.client.session.ClientSessionCreator.connect(ClientSessionCreator.java:57) ~[sshd-core-2.9.2.jar:2.9.2] ``` ### Other information our code :  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #310: What will cause the failure to open the channel
garyiscoding commented on issue #310:
URL: https://github.com/apache/mina-sshd/issues/310#issuecomment-1385029023
long openChannelTimeout = 500L;
try (ChannelExec channel = session.createExecChannel(command);
ByteArrayOutputStream outputStream = new
ByteArrayOutputStream();
ByteArrayOutputStream errorStream = new
ByteArrayOutputStream()) {
channel.setOut(outputStream);
channel.setErr(errorStream);
channel.open().verify(openChannelTimeout);
channel.waitFor(EnumSet.of(CLOSED), execTimeout);
Integer exitCode = channel.getExitStatus();
String outputStr =
StringUtils.chomp(outputStream.toString());
String errorStr = StringUtils.chomp(errorStream.toString());
}
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #310: What will cause the failure to open the channel
garyiscoding commented on issue #310:
URL: https://github.com/apache/mina-sshd/issues/310#issuecomment-1385028394
`long openChannelTimeout = 500L;
try (ChannelExec channel = session.createExecChannel(command);
ByteArrayOutputStream outputStream = new
ByteArrayOutputStream();
ByteArrayOutputStream errorStream = new
ByteArrayOutputStream()) {
channel.setOut(outputStream);
channel.setErr(errorStream);
channel.open().verify(openChannelTimeout);
channel.waitFor(EnumSet.of(CLOSED), execTimeout);
Integer exitCode = channel.getExitStatus();
String outputStr =
StringUtils.chomp(outputStream.toString());
String errorStr = StringUtils.chomp(errorStream.toString());
}`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #310: What will cause the failure to open the channel
garyiscoding commented on issue #310:
URL: https://github.com/apache/mina-sshd/issues/310#issuecomment-1385028733
`long openChannelTimeout = 500L;
try (ChannelExec channel = session.createExecChannel(command);
ByteArrayOutputStream outputStream = new
ByteArrayOutputStream();
ByteArrayOutputStream errorStream = new
ByteArrayOutputStream()) {
channel.setOut(outputStream);
channel.setErr(errorStream);
channel.open().verify(openChannelTimeout);
channel.waitFor(EnumSet.of(CLOSED), execTimeout);
Integer exitCode = channel.getExitStatus();
String outputStr =
StringUtils.chomp(outputStream.toString());
String errorStr = StringUtils.chomp(errorStream.toString());
}`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #310: What will cause the failure to open the channel
garyiscoding commented on issue #310: URL: https://github.com/apache/mina-sshd/issues/310#issuecomment-1385023724 When the service is first deployed, there is no error. After running for a while, this error occurs  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #310: What will cause the failure to open the channel
tomaswolf commented on issue #310: URL: https://github.com/apache/mina-sshd/issues/310#issuecomment-1384481173 From looking at where this exception is created, it seems that it indicates a failure in TCP/IP port fowarding to connect to the requested external port. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #311: Issue related to CVE-2022-45047
tomaswolf commented on issue #311: URL: https://github.com/apache/mina-sshd/issues/311#issuecomment-1384457928 We wrote in the [CVE announcement](https://www.mail-archive.com/users@mina.apache.org/msg06948.html), also [linked at the NIST](https://www.mail-archive.com/dev@mina.apache.org/msg39312.html), that all versions <= 2.9.1 were affected. We also gave steps how to mitigate the vulnerability. Beyond that, I cannot give any further advice. I don't have the time to analyze v2.7.0 to see if that version might use it even if you set a different key provider. In current master code, there is exactly one place in non-test code where the SimpleGeneratorHostKeyProvider is used. (In SshServerCliSupport.resolveServerKeys().) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] 4devwithgit opened a new issue, #311: Issue related to CVE-2022-45047
4devwithgit opened a new issue, #311:
URL: https://github.com/apache/mina-sshd/issues/311
### Version
2.7.0
### Bug description
This is in regards to the security vulnerability,
https://nvd.nist.gov/vuln/detail/CVE-2022-45047
In our code implementation for **apache sshd server of 2.7.0**, we are using
KeyPairProvider Interface, with below code snippet. So, I am reviewing whether
we are really vulnerable to the above security issue.
To me it looks like, internally apache might still call
SimpleGeneratorHostKeyProvider and hence vulnerability is there, and we need to
upgrade to the latest version.
import org.apache.sshd.common.keyprovider.KeyPairProvider;
...
KeyPair hostKeyPair =
readKeyPair(config.getHostIdentityKey());
if (hostKeyPair != null) {
KeyPairProvider serverKeys =
getProvider(hostKeyPair);
sshdServer.setKeyPairProvider(serverKeys);
}
Thanks
Dev
### Actual behavior
Question
### Expected behavior
security issue
### Relevant log output
_No response_
### Other information
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding opened a new issue, #310: What will cause the failure to open the channel?
garyiscoding opened a new issue, #310: URL: https://github.com/apache/mina-sshd/issues/310 Hello, may I ask what will cause the failure to open the channel? Is this the exception caught in the log org.apache.sshd.common.SshException: DefaultOpenFuture[ChannelExec[id=123, recipient=-1]-ClientSessionImpl[root@/10.155.109.229:22]]: Failed (SshChannelOpenException) to execute: open failed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding closed issue #306: Client startup sometimes take a long time
garyiscoding closed issue #306: Client startup sometimes take a long time URL: https://github.com/apache/mina-sshd/issues/306 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Ingo13F commented on issue #309: Allow for the use of HTTP or SOCKS proxies
Ingo13F commented on issue #309: URL: https://github.com/apache/mina-sshd/issues/309#issuecomment-1378550899 Ah, yes sure. That's more of a wording issue then. I concur: The code from jGit for proxy handling should somehow make its way into MINA SSHD and all is good. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Ingo13F commented on issue #309: Allow for the use of HTTP or SOCKS proxies
Ingo13F commented on issue #309: URL: https://github.com/apache/mina-sshd/issues/309#issuecomment-1378490095 If I see this correctly this would be accomplished by subclassing SshClient and overwriting the connect method as well as implementing the ProxyConnectors. In my opinion, this is not code that the user of a library should write. Especially subclassing the client implementation to change its behavior doesn't sound right to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #309: Allow for the use of HTTP or SOCKS proxies
tomaswolf commented on issue #309: URL: https://github.com/apache/mina-sshd/issues/309#issuecomment-1378337756 It is possible to connect via HTTP or SOCKS proxies with Apache MINA sshd. But the library does not provide this feature out of the box; users have to write their own code. See [SSHD-1008](https://issues.apache.org/jira/browse/SSHD-1008?focusedCommentId=17121296=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17121296). Also related: [SSHD-751](https://issues.apache.org/jira/browse/SSHD-751) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] Ingo13F opened a new issue, #309: Allow for the use of HTTP or SOCKS proxies
Ingo13F opened a new issue, #309: URL: https://github.com/apache/mina-sshd/issues/309 ### Description I am using MINA SSHD as part of Spring Integration 6.0.1 since it replaced the JSch SSH implementation there. However I was using a HTTP proxy to connect with JSch and this seems to be no longer possible with MINA because it supports only SSH jump hosts as a proxy. So my request would be to implement a more flexible approach to proxies and also allow for the use of HTTP and SOCKS proxies., ### Motivation This feature is needed to make it possible to use MINA SSHD and the frameworks that depend on it in environments where the server being accessed can only be reached via an HTTP/SOCKS proxy. Especially In scenarios where MINA SSHD is used for transferring data via SFTP this seems not to be a far-fetched scenario. ### Alternatives considered An alternative would be to install a jump host with internet access. However, in larger organizations this might not always be possible or takes a long time to make it through all the corporate red tape. ### Additional context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
tomaswolf commented on issue #302: URL: https://github.com/apache/mina-sshd/issues/302#issuecomment-1376388012 @zmrush can you give #308 a try? I think that should avoid this endless loop. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #308: GH-302: Fail writes after SSH session is closed
tomaswolf opened a new pull request, #308: URL: https://github.com/apache/mina-sshd/pull/308 If there is an exception during KEX that causes the SSH session to be closed, fail any further write attempts by throwing an SshException. Otherwise KeyExchangeMessageHandler.writeOrEnqueue() might loop forever since the KexState will never be DONE. Bug: https://github.com/apache/mina-sshd/issues/302 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #293: Performance problems in tests (NIO2 and MINA, Linux only)
tomaswolf closed issue #293: Performance problems in tests (NIO2 and MINA, Linux only) URL: https://github.com/apache/mina-sshd/issues/293 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #307: GH-293: Handle SFTP buffer sizes > server limit better
tomaswolf merged PR #307: URL: https://github.com/apache/mina-sshd/pull/307 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #293: Performance problems in tests (NIO2 and MINA, Linux only)
tomaswolf commented on issue #293: URL: https://github.com/apache/mina-sshd/issues/293#issuecomment-1374645896 The problem in SFTP is caused by excessively jumping back and forth in the file on the server side. It manifests only with NIO2 and MINA but not with Netty because timing is different and the files end up being read more or less sequentially, or the backwards jumps are within some OS buffer size. With NIO2 and MINA, more initial read requests appear to be handled before a backwards jump occurs, which then leads to more and larger backwards jumps if one keeps issuing asynchronous requests. I did not analyze why the problem did not occur on Windows or locally on OS X; perhaps these OSes handle this better than Linux, or the request timings and their handling are more like in the Netty/Linux case. I still have no idea why the problem occurs from a particular GitHub CI build on. Perhaps something in the Linux container used to run the tests changed. In any case I have not found any particular commit from which on the performance would have dropped markedly on Linux; the problem was apparent in all runs in my local CentOS 7 VM, no matter how far back I went. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere closed pull request #25: DIRMINA-1124 : make NioProcessor and NioSocketAcceptor extendable by removing final from class declaration
jon-valliere closed pull request #25: DIRMINA-1124 : make NioProcessor and NioSocketAcceptor extendable by removing final from class declaration URL: https://github.com/apache/mina/pull/25 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere commented on pull request #25: DIRMINA-1124 : make NioProcessor and NioSocketAcceptor extendable by removing final from class declaration
jon-valliere commented on PR #25: URL: https://github.com/apache/mina/pull/25#issuecomment-1374629832 Closing because the patch was merged into main on https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=53d96b92d4bf14fad2b87d8fdeca4ebc5019b6d8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere merged pull request #33: Fixed small typo in `SslFilter`
jon-valliere merged PR #33: URL: https://github.com/apache/mina/pull/33 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere merged pull request #37: write direct buffer only once in APR
jon-valliere merged PR #37: URL: https://github.com/apache/mina/pull/37 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere commented on pull request #37: write direct buffer only once in APR
jon-valliere commented on PR #37: URL: https://github.com/apache/mina/pull/37#issuecomment-1374624355 I take it back, since the `position()` is used when writing, it makes sense not to move the pointer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] jon-valliere commented on pull request #37: write direct buffer only once in APR
jon-valliere commented on PR #37: URL: https://github.com/apache/mina/pull/37#issuecomment-1374621868 I spent the last 10 minutes trying to find the source code for `sendb`. The only thing I can find is the JNI definition for the function. Usually when a function takes in a `ByteBuffer` as an argument, it always moves the pointer forward as data is either read or written. Can you point me to the code which shows that is not happening? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #307: GH-293: Handle SFTP buffer sizes > server limit better
tomaswolf opened a new pull request, #307: URL: https://github.com/apache/mina-sshd/pull/307 If a client uses an SFTP buffer size greater than the maximum amount of data the server is willing to return for an individual read request, data will be delivered with "holes". For instance, if the server limit is 63kB, and the client uses a buffer size of 64kB, it will issue requests to read 64kb at offset 0, then 64kB at offset 65536, and so on. But it will get only 63kB at offset 0 and 63kB at offset 65536. When it notices that, it'll request the missing 1kB at offset 64512 synchronously. In a large file, this can lead to jumping back and forth in the file frequently if the client issues new requests after having read missing data, because the very next read again will be short, but the server may have already skipped forward again to satisfy the new requests. Avoid that by not issuing new requests until the client has caught up. That way, the server has to move backwards in the file far less often and can serve the data much faster and smoother. (An alternative or additional improvement in this area might be to make the server-side implementation smarter about re-ordering read requests. The current implementation just serves them as they come, but the SFTP draft RFCs explicitly allow some re-ordering. The server could use a priority queue ordered by offset, trying on _its_ side to avoid excessive back and forth. Some care would have to be taken to deal with overlapping read and write requests.) Fixes #293. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] subes opened a new pull request, #37: write direct buffer only once
subes opened a new pull request, #37: URL: https://github.com/apache/mina/pull/37 fixes an endless loop when writing a direct buffer in APR -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #283: Client:Sent SSH_MSG_USERAUTH_REQUEST twice even PASSWORD_PROMPTS=1
tomaswolf closed issue #283: Client:Sent SSH_MSG_USERAUTH_REQUEST twice even PASSWORD_PROMPTS=1 URL: https://github.com/apache/mina-sshd/issues/283 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #284: GH-283: Fix handling of CoreModuleProperties.PASSWORD_PROMPTS
tomaswolf merged PR #284: URL: https://github.com/apache/mina-sshd/pull/284 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #306: Client startup sometimes take a long time
tomaswolf commented on issue #306: URL: https://github.com/apache/mina-sshd/issues/306#issuecomment-1369844383 Keeping the client open is certainly faster, but re-creating clients is also possible. JGit does so, for instance, and we never got any complaints. To find out why recreating clients sometimes takes such a long time in your setting, you'd have to profile your application. Perhaps that gives some insights. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #306: Client startup sometimes take a long time
garyiscoding commented on issue #306: URL: https://github.com/apache/mina-sshd/issues/306#issuecomment-1369729305 > 9783ms is 9.783s, not 90s. > > It is impossible to answer this question from the information given. Might be anything, like the JVM having to load classes first, or garbage collection skewing the timing, or a virus scanner interfering, or anything else. We need to log in to different machines frequently to execute commands. We used to create a new client, then a new session, and then execute the command. After executing the command, we close the session and client. As a result, the next client creation will take a long time, even 200 seconds. Later we tried to keep the client open and create a new session when we needed to execute a command. The situation of delay does not appear any more. Is the method I used before wrong？ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding closed issue #306: Client startup sometimes take a long time
garyiscoding closed issue #306: Client startup sometimes take a long time URL: https://github.com/apache/mina-sshd/issues/306 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding commented on issue #306: Client startup sometimes take a long time
garyiscoding commented on issue #306: URL: https://github.com/apache/mina-sshd/issues/306#issuecomment-1369720307 > 9783ms is 9.783s, not 90s. > > It is impossible to answer this question from the information given. Might be anything, like the JVM having to load classes first, or garbage collection skewing the timing, or a virus scanner interfering, or anything else. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #306: Client startup sometimes take a long time
tomaswolf commented on issue #306: URL: https://github.com/apache/mina-sshd/issues/306#issuecomment-1369586061 9783ms is 9.783s, not 90s. It is impossible to answer this question from the information given. Might be anything, like the JVM having to load classes first, or garbage collection skewing the timing, or a virus scanner interfering, or anything else. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] garyiscoding opened a new issue, #306: Client startup sometimes take a long time
garyiscoding opened a new issue, #306:
URL: https://github.com/apache/mina-sshd/issues/306
### Version
2.9.2
### Bug description
Sometimes the client starts quickly and sometimes slowly.
long startTime = System.currentTimeMillis();
client = SshClient.setUpDefaultClient();
client.start();
LOGGER.info(String.format("start client cost [%s] ms",
System.currentTimeMillis() - startTime));
When it is slow, it takes about 90 seconds to start. What is the solution
### Actual behavior
start client cost [9783] ms
### Expected behavior
start client cost [200] ms
### Relevant log output
_No response_
### Other information
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #293: Performance problems in tests (NIO2 and MINA, Linux only)
tomaswolf commented on issue #293: URL: https://github.com/apache/mina-sshd/issues/293#issuecomment-1369168078 This is also reproducible for me in a CentOS 7 virtual machine running locally. From the logs I see that with NIO2 and MINA, there is a 40ms delay for getting these extra 1kB chunks, which isn't present in the Netty logs. But I have no idea yet where these 40ms come from. Bisecting did not yield any insights. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #283: Client:Sent SSH_MSG_USERAUTH_REQUEST twice even PASSWORD_PROMPTS=1
tomaswolf commented on issue #283: URL: https://github.com/apache/mina-sshd/issues/283#issuecomment-1369166287 Absent an answer, I've pushed a fix to PR #284. It implements `CoreModuleProperties.PASSWORD_PROMPTS`as the equivalent of the OpenSSH config `NumberOfPasswordPrompts`. Only interactive authentication attempts count towards the limit. There is no special guard against a server that keeps sending challenges in keyboard-interactive authentication. Normally such behavior would be caught by either of the following: * supplied passwords for non-interactively authenticating being exhausted, * the user cancelling authentication on the umpteenth interactive dialog for a challenge, * or the client's authentication time-out expiring. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #300: The variable sender of channelOpenConfirmation is possibly negative
tomaswolf closed issue #300: The variable sender of channelOpenConfirmation is possibly negative URL: https://github.com/apache/mina-sshd/issues/300 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #305: GH-300: SSH_MSG_CHANNEL_OPEN_CONFIRMATION: channel ID is unsigned
tomaswolf merged PR #305: URL: https://github.com/apache/mina-sshd/pull/305 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #305: GH-300: SSH_MSG_CHANNEL_OPEN_CONFIRMATION: channel ID is unsigned
tomaswolf opened a new pull request, #305: URL: https://github.com/apache/mina-sshd/pull/305 Fix reading the id from the message, and add a test in which the server uses artificially high channel IDs beyond Integer.MAX_VALUE. Fixes #300. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #298: Server side heartbeat not working
tomaswolf closed issue #298: Server side heartbeat not working URL: https://github.com/apache/mina-sshd/issues/298 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #303: GH-298: Start service in AbstractServerSession
tomaswolf merged PR #303: URL: https://github.com/apache/mina-sshd/pull/303 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] cl728 closed issue #304: How to disable the warning "Server at xxxx preseneted unverfied EC key"
cl728 closed issue #304: How to disable the warning "Server at preseneted unverfied EC key" URL: https://github.com/apache/mina-sshd/issues/304 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] cl728 opened a new issue, #304: How to disable the warning "Server at xxxx preseneted unverfied EC key"
cl728 opened a new issue, #304: URL: https://github.com/apache/mina-sshd/issues/304 ### Version 2.7.0 ### Bug description every time when the program connects to the remote host using apache-mina-sshd will print the WARN log like "Server at xxx presented unverfied EC key", I wonder how to disable it? ### Actual behavior every time when the program connects to the remote host using apache-mina-sshd will print the WARN log like "Server at xxx presented unverfied EC key" ### Expected behavior No WARN log like "Server at xxx preseneted unverfied EC key" be printed. ### Relevant log output _No response_ ### Other information _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #303: GH-298: Start service in AbstractServerSession
tomaswolf opened a new pull request, #303: URL: https://github.com/apache/mina-sshd/pull/303 Services need to be started. In particular, the connection service starts its heartbeat, if configured, when started. It was already noticed in commit e74e2041 that the server-side did not start services, but at that time the effect was not recognized because tests were too unstable back then. A test for server-side heartbeats was also missing. Fixes #298. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #298: Server side heartbeat not working
tomaswolf commented on issue #298: URL: https://github.com/apache/mina-sshd/issues/298#issuecomment-1365428807 Indeed; you're right. It looks like this never worked, and was not caught because there was no test for server-side heartbeats. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] thevipwan commented on issue #298: Server side heartbeat not working
thevipwan commented on issue #298: URL: https://github.com/apache/mina-sshd/issues/298#issuecomment-1364823374 switch to version 2.9.2 but still not work；I use debug log and Wireshark(Capture port traffic) monitor heartbeat，I'm so confused about it, can you give me correct example code? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #297: SSHD Client failing on private key file with key password
tomaswolf closed issue #297: SSHD Client failing on private key file with key password URL: https://github.com/apache/mina-sshd/issues/297 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #299: GH-297: SshClient: auto-configure for encrypted key identities
tomaswolf merged PR #299: URL: https://github.com/apache/mina-sshd/pull/299 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] zmrush commented on issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
zmrush commented on issue #302: URL: https://github.com/apache/mina-sshd/issues/302#issuecomment-1364450878 > Not enough information. Please provide full jstack traces as text file. If you have some code that can reproduce the behavior reliably that would also be helpful. > > With just the information given, I don't see how one could even begin to investigate. i cannot paste all the jstack traces,because it may explode some information about my company, but it goes into infinite loop.you can see below two images,it goes in the "for;;" not ends   -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] zmrush commented on issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
zmrush commented on issue #302: URL: https://github.com/apache/mina-sshd/issues/302#issuecomment-1364450488 it happens occasionally,not always.i guess that when we write packet, the thread is in requestNewKeysExchange,so kexDone not fulfilled and the thread goes into "block = kexFlushedFuture;" and unfortunately, the connection is done,so the kexDone never done, and it goes into infinite loop -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
tomaswolf commented on issue #302: URL: https://github.com/apache/mina-sshd/issues/302#issuecomment-1364179109 Not enough information. Please provide full jstack traces as text file. If you have some code that can reproduce the behavior reliably that would also be helpful. With just the information given, I don't see how one could even begin to investigate. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] zmrush commented on issue #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
zmrush commented on issue #302: URL: https://github.com/apache/mina-sshd/issues/302#issuecomment-1363931090  ![Uploading 76694429-AB75-4229-A733-7A51F5776628.png…]() -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] zmrush opened a new issue, #302: requestNewKeysExchange may cause KeyExchangeMessageHandler into dead lock,cpu 100%
zmrush opened a new issue, #302: URL: https://github.com/apache/mina-sshd/issues/302 ### Version 2.9.1 ### Bug description i observed in cases， the write packet thread is always running and in the interval i saw "equestNewKeysExchange(ClientSessionImpl[root@/47.104.92.124:22]) Initiating key re-exchange method:o.a.s.c.s.ClientSessionImpl(AbstractSession.java:2404) " in log ### Actual behavior after i saw log "equestNewKeysExchange(ClientSessionImpl[root@/47.104.92.124:22]) Initiating key re-exchange method:o.a.s.c.s.ClientSessionImpl(AbstractSession.java:2404)",the write packet thread is soar to 100%,not stopped ### Expected behavior i expect when the connection is closed the cpu is down,and the thread is stopped ### Relevant log output ```Shell equestNewKeysExchange(ClientSessionImpl[root@/47.104.92.124:22]) Initiating key re-exchange method:o.a.s.c.s.ClientSessionImpl(AbstractSession.java:2404) ``` ### Other information _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #298: Server side heartbeat not working
tomaswolf commented on issue #298: URL: https://github.com/apache/mina-sshd/issues/298#issuecomment-1363696280 1. I see that you are using version 2.7.0. Please try with 2.9.2, or with the master version. 2. How do you verify whether the client gets heartbeat messages? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] thevipwan commented on issue #298: Server side heartbeat not working
thevipwan commented on issue #298: URL: https://github.com/apache/mina-sshd/issues/298#issuecomment-1363561355 > SessionHeartbeatController.HeartbeatType.IGNORE Try this, but still can't get any heartbeats -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] jiang1308061292 commented on issue #300: The variable sender of channelOpenConfirmation is possibly negative
jiang1308061292 commented on issue #300: URL: https://github.com/apache/mina-sshd/issues/300#issuecomment-1363531638 > Yes. Do you want to provide a PR? Yes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #300: The variable sender of channelOpenConfirmation is possibly negative
tomaswolf commented on issue #300: URL: https://github.com/apache/mina-sshd/issues/300#issuecomment-1363404457 Yes. Do you want to provide a PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #301: Get sender from cmd SSH_MSG_CHANNEL_OPEN_CONFIRMATION wrong could result exception
tomaswolf closed issue #301: Get sender from cmd SSH_MSG_CHANNEL_OPEN_CONFIRMATION wrong could result exception URL: https://github.com/apache/mina-sshd/issues/301 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #301: Get sender from cmd SSH_MSG_CHANNEL_OPEN_CONFIRMATION wrong could result exception
tomaswolf commented on issue #301: URL: https://github.com/apache/mina-sshd/issues/301#issuecomment-1362858864 This is a duplicate of #300. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] AricBear opened a new issue, #301: Get sender from cmd SSH_MSG_CHANNEL_OPEN_CONFIRMATION wrong could result exception
AricBear opened a new issue, #301:
URL: https://github.com/apache/mina-sshd/issues/301
### Version
2.9.2
### Bug description
While opening a channel, mina deals cmd of SSH_MSG_CHANNEL_OPEN_CONFIRMATION
in
org.apache.sshd.common.session.helpers.AbstractConnectionService#channelOpenConfirmation.
```java
public void channelOpenConfirmation(Buffer buffer) throws IOException {
Channel channel =
getChannel(SshConstants.SSH_MSG_CHANNEL_OPEN_CONFIRMATION, buffer);
if (channel == null) {
return; // debug breakpoint
}
int sender = buffer.getInt();
long rwsize = buffer.getUInt();
long rmpsize = buffer.getUInt();
if (log.isDebugEnabled()) {
log.debug("channelOpenConfirmation({})
SSH_MSG_CHANNEL_OPEN_CONFIRMATION sender={}, window-size={}, packet-size={}",
channel, sender, rwsize, rmpsize);
}
/*
* NOTE: the 'sender' of the SSH_MSG_CHANNEL_OPEN_CONFIRMATION is
the recipient on the client side - see rfc4254
* section 5.1:
*
* 'sender channel' is the channel number allocated by the other side
*
* in our case, the server
*/
channel.handleOpenSuccess(sender, rwsize, rmpsize, buffer);
}
```
mina defines sender as int( `int sender = buffer.getInt();` ), while sender
should be UINT32. Therefore , here could be a situation, when sender is bigger
than 0x7fff, and turns to be a minus int, and then be set as channel's
recipient.
When mina uses channel's recipient later, e.g.
org.apache.sshd.common.channel.ChannelAsyncOutputStream#createSendBuffer
```java
protected Buffer createSendBuffer(Buffer buffer, Channel channel, int
length) {
SessionContext.validateSessionPayloadSize(length, "Invalid send
buffer length: %d");
Session s = channel.getSession();
Buffer buf = s.createBuffer(cmd, length + 12);
buf.putUInt(channel.getRecipient());
if (cmd == SshConstants.SSH_MSG_CHANNEL_EXTENDED_DATA) {
buf.putUInt(SshConstants.SSH_EXTENDED_DATA_STDERR);
}
buf.putUInt(length);
buf.putRawBytes(buffer.array(), buffer.rpos(), length);
buffer.rpos(buffer.rpos() + length);
return buf;
}
```
when put channel's recipient into buffer, `putUInt(long i)` checks input i,
if i is a minus number, an IllegalArgumentException would be thrown, and the
channel would be closed.
I searched git log, found out this problem is related to [SSHD-1244]. Lyor
Goldstein changed lots of int variables into long to hold uint32 values, but
unfortunately he missed some line. Line `int sender = buffer.getInt();` in
`channelOpenConfirmation()` is untouched while
`org.apache.sshd.common.session.helpers.AbstractConnectionService#channelOpen`
is correctly changed.
Not sure whether there were more left unmodified, since there were lots code
change in [SSHD-1244]. We should review code to make sure.
### Actual behavior
I use mina sshd as server. A client is connecting to server, send
SSH_MSG_CHANNEL_OPEN_CONFIRMATION while sender is something like 0xFF010015,
then exception is thrown , session is closed.
### Expected behavior
It should connect like any other client.
### Relevant log output
```Shell
2022-12-19T15:32:57,781 | DEBUG | MinaProcessor-11 |
ServerSessionImpl|doHandleMessage() 551 |
org.apache.sshd.common.session.helpers.AbstractSession | | | |
doHandleMessage(ServerSessionImpl[user@/120.126.12.100:29030]) process #8
SSH_MSG_CHANNEL_OPEN_CONFIRMATION
2022-12-19T15:32:57,781 | DEBUG | MinaProcessor-11 |
ServerConnectionService |channelOpenConfirmation() 534 |
org.apache.sshd.common.session.helpers.AbstractConnectionService | | | |
channelOpenConfirmation(TcpipClientChannel[id=0,
recipient=-1]-ServerSessionImpl[user@/120.126.12.100:29030])
SSH_MSG_CHANNEL_OPEN_CONFIRMATION sender=-2147418110, window-size=131072,
packet-size=32768
2022-12-19T15:32:57,781 | DEBUG | MinaProcessor-11 |
TcpipClientChannel |setRecipient() 172 |
org.apache.sshd.common.channel.AbstractChannel | | | |
setRecipient(TcpipClientChannel[id=0,
recipient=-1]-ServerSessionImpl[user@/120.126.12.100:29030])
recipient=-2147418110
java.lang.IllegalArgumentException: Invalid UINT32 value: -2147418097
at
org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
~[sshd-common-2.9.2.jar:2.9.2]
at
org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
~[sshd-common-2.9.2.jar:2.9.2]
at
[GitHub] [mina-sshd] ascertsimonm commented on issue #297: SSHD Client failing on private key file with key password
ascertsimonm commented on issue #297: URL: https://github.com/apache/mina-sshd/issues/297#issuecomment-1362725809 Heya Yes, something like that but having things done automatically is better. Thanks Simon -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] jiang1308061292 commented on issue #300: The variable sender of channelOpenConfirmation is possibly negative
jiang1308061292 commented on issue #300:
URL: https://github.com/apache/mina-sshd/issues/300#issuecomment-1362576297
public void channelOpenConfirmation(Buffer buffer) throws IOException {
Channel channel = this.getChannel((byte)91, buffer);
if (channel != null) {
// int sender = buffer.getInt();
long sender = buffer.getUInt();
long rwsize = buffer.getUInt();
long rmpsize = buffer.getUInt();
if (this.log.isDebugEnabled()) {
this.log.debug("channelOpenConfirmation({})
SSH_MSG_CHANNEL_OPEN_CONFIRMATION sender={}, window-size={}, packet-size={}",
new Object[]{channel, sender, rwsize, rmpsize});
}
channel.handleOpenSuccess((long)sender, rwsize, rmpsize, buffer);
}
}
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] jiang1308061292 opened a new issue, #300: The variable sender of channelOpenConfirmation is possibly negative
jiang1308061292 opened a new issue, #300: URL: https://github.com/apache/mina-sshd/issues/300 ### Version 2.9.2 ### Bug description The remote side then decides whether it can open the channel, and responds with either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE. byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION uint32recipient channel uint32sender channel uint32initial window size uint32maximum packet size channel type specific data follows the sender is uint32，but the variable sender of channelOpenConfirmation is int. if sender is more than 2147483647, the variable sender of channelOpenConfirmation will be negative and cause the IllegalArgumentException: Invalid UINT32. ### Actual behavior if the buffer related to sender is -128 1 0 1, the sender will be -2147418111 and it cause cause the IllegalArgumentException: Invalid UINT32. ### Expected behavior if sender is more than 2147483647，it Shouldn't cause the IllegalArgumentException: Invalid UINT32. ### Relevant log output ```Shell IllegalArgumentException: Invalid UINT32 value: -2147418111 java.lang.IllegalArgumentException: Invalid UINT32 value: -2147418111 at org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.util.buffer.BufferUtils.validateUint32Value(BufferUtils.java:701) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.util.buffer.Buffer.putUInt(Buffer.java:720) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.channel.ChannelAsyncOutputStream.createSendBuffer(ChannelAsyncOutputStream.java:393) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.channel.ChannelAsyncOutputStream.writePacket(ChannelAsyncOutputStream.java:338) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.channel.ChannelAsyncOutputStream.doWriteIfPossible(ChannelAsyncOutputStream.java:215) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.channel.ChannelAsyncOutputStream.writeBuffer(ChannelAsyncOutputStream.java:110) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.forward.DefaultForwarder$StaticIoHandler.lambda$messageReceived$2(DefaultForwarder.java:1063) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.util.threads.ThreadUtils.runAsInternal(ThreadUtils.java:68) ~[sshd-common-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.common.forward.DefaultForwarder$StaticIoHandler.messageReceived(DefaultForwarder.java:1063) ~[sshd-core-2.9.2-h0.gdd.pub.r1.jar:2.9.2-h0.gdd.pub.r1] at org.apache.sshd.mina.MinaService.messageReceived(MinaService.java:156) ~[sshd-mina-2.9.2.jar:2.9.2] at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:1015) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:643) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1224) ~[mina-core-2.1.6.jar:?] at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1213)
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #299: GH-297: SshClient: auto-configure for encrypted key identities
tomaswolf opened a new pull request, #299: URL: https://github.com/apache/mina-sshd/pull/299 Automatically configure KeyIdentityProviders to use the FilePasswordProvider set on the client if they don't have an explicit password provider already. This simplifies setting up a client to deal with encrypted private keys: set a FilePasswordProvider on the client, and set a FileKeyPairProvider with the key file(s), and off it goes. Previously, setting a FilePasswordProvider on an SshClient only had an effect for identity files specified in a HostConfigEntry. For other use cases, a FilePasswordProvider had to be set explicitly on the FileKeyPairProvider. (Which is still possible, and takes precedence over the new auto-configuration.) This also makes it possible to use SshClientMain with an encrypted private key given on the command-line via the -i option. Fixes #297. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #294: Memory Leak in SftpFileSystemProvider
tomaswolf closed issue #294: Memory Leak in SftpFileSystemProvider URL: https://github.com/apache/mina-sshd/issues/294 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #295: GH-294: Fix memory leaks in SftpFileSystemProvider
tomaswolf merged PR #295: URL: https://github.com/apache/mina-sshd/pull/295 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf closed issue #298: Server side heartbeat not working
tomaswolf closed issue #298: Server side heartbeat not working URL: https://github.com/apache/mina-sshd/issues/298 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #298: Server side heartbeat not working
tomaswolf commented on issue #298: URL: https://github.com/apache/mina-sshd/issues/298#issuecomment-1362479575 Why did you expect any heartbeats to be sent when you set heartbeat type `NONE`? Try `SessionHeartbeatController.HeartbeatType.IGNORE`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] thevipwan opened a new issue, #298: Server side heartbeat not working
thevipwan opened a new issue, #298:
URL: https://github.com/apache/mina-sshd/issues/298
### Version
master
### Bug description
dependency：
```
org.apache.sshd
sshd-core
2.7.0
```
Code：
```
SshServer sshd = SshServer.setUpDefaultServer();
sshd.setPort();
sshd.setShellFactory(InteractiveProcessShellFactory.INSTANCE);
sshd.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.NONE,
Duration.ofSeconds(5));
sshd.setKeyPairProvider(new
ClassLoadableResourceKeyPairProvider(getClass().getClassLoader(), "rsa.key"));
sshd.setPasswordAuthenticator((username, password, session) ->
username.equals(password));
sshd.start();
log.info("SSHD server started");
```
ssh Client:
```
user/passwd = test
ssh test@127.0.0.1 -p
```
### Actual behavior
read [Server Setup
Manual](https://github.com/apache/mina-sshd/blob/master/docs/server-setup.md)
last section
I with my SSHD has ServerSide heartbeat，But setSessionHeartbeat API didn't
working, ssh session didn't get any interval heartbeat
### Expected behavior
SSHD automatic send heartbeat message for each ssh session
### Relevant log output
_No response_
### Other information
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #297: SSHD Client failing on private key file with key password
tomaswolf commented on issue #297: URL: https://github.com/apache/mina-sshd/issues/297#issuecomment-1361969405 If you mean that you added in [SshClientCliSupport, line 508](https://github.com/apache/mina-sshd/blob/78ed6bc9/sshd-cli/src/main/java/org/apache/sshd/cli/client/SshClientCliSupport.java#L508) something like ``` provider.setPasswordFinder(client.getFilePasswordProvider()); ``` I agree that this is one way of solving this. However, I wonder if this was not better done automatically in [SshClient](https://github.com/apache/mina-sshd/blob/78ed6bc9/sshd-core/src/main/java/org/apache/sshd/client/SshClient.java#L755) by making sure the session's effective keypair provider does have a password finder set. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] ascertsimonm opened a new issue, #297: SSHD Client failing on private key file with key password
ascertsimonm opened a new issue, #297: URL: https://github.com/apache/mina-sshd/issues/297 ### Version 2.9.2 ### Bug description When attempting to run the SSH client with that private key file that is protected with a password the Mina SSH client doesn't make the connection. The client was run using the command `java -jar MinaSshClient-2.9.2.jar -i K:\id_rsa myuser@192.168.247.129` ### Actual behavior The client seems to fail to load the key resource with the following warning `WARNING: org.apache.sshd.cli.client.SshCl: Failed (FailedLoginException) to load key resource=K:\id_rsa: No password provider for encrypted key in K:\id_rsa` the connection subsequently fails with a "No more authentication methods available" ### Expected behavior The client should prompt for a password for the key file or have another command line parameter to specify it. ### Relevant log output _No response_ ### Other information I did a bit of debugging on this and for whatever reason the prompt for the password for the private key file isn't being triggered by the code in the _SshClientCliSupport_, _setupSessionIdentities_ method. Whether or not it's the correct solution what I did in my own code is I used the setPasswordFinder method on the FileKeyPairProvider with the same code segment as for the client `setFilePasswordProvider` and it seemed to work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] onyas commented on pull request #242: Fix: close session when timeout during connect
onyas commented on PR #242: URL: https://github.com/apache/mina-sshd/pull/242#issuecomment-1360632397 Got it. Thank you for your contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #296: [Support Request] Read only VirtualFileSystemFactory
tomaswolf commented on issue #296: URL: https://github.com/apache/mina-sshd/issues/296#issuecomment-1360277406 I looked at that a while ago myself in the context of [Gerrit issue 15944](https://bugs.chromium.org/p/gerrit/issues/detail?id=15944). I didn't see immediately how to do that. Perhaps someone more knowledgeable with FileSystems can chime in here. To enforce read-only SFTP access, another approach might be using a `org.apache.sshd.contrib.server.subsystem.sftp.SimpleAccessControlSftpEventListener.READ_ONLY_ACCESSOR`. Something like ``` SftpSubsystemFactory.Builder builder = new SftpSubsystemFactory.Builder(); builder.addSftpEventListener(SimpleAccessControlSftpEventListener.READ_ONLY_ACCESSOR); server.setSubsystemFactories(Collections.singletonList(builder.build())); // Actually, add the SFTP factory to whatever other factories there are. server.setFileSystemFactory(new VirtualFileSystemFactory(rootPath)); ``` Otherwise look at `org.apache.sshd.common.file.root.RootedFileSystem`. It does have an `isReadOnly()` method. It might perhaps be necessary to override more methods to make it truly read-only, and you'd need a provider for it, and probably override parts of the `VirtualFileSystemFactory` to use your own read-only filesystem implementation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] ThanasisBarekas opened a new issue, #296: [Support Request] Read only VirtualFileSystemFactory
ThanasisBarekas opened a new issue, #296: URL: https://github.com/apache/mina-sshd/issues/296 Hello, Is it possible to create a read only VirtualFileSystemFactory ? if yes can you please share an example ? Thank you, Thanasis -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on a diff in pull request #295: GH-294: Fix memory leaks in SftpFileSystemProvider
tomaswolf commented on code in PR #295: URL: https://github.com/apache/mina-sshd/pull/295#discussion_r1053561160 ## sshd-sftp/src/test/java/org/apache/sshd/sftp/client/fs/SftpFileSystemTest.java: ## @@ -87,6 +89,7 @@ import org.junit.runners.MethodSorters; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import org.testcontainers.shaded.org.apache.commons.io.output.ByteArrayOutputStream; Review Comment: Fixed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on a diff in pull request #295: GH-294: Fix memory leaks in SftpFileSystemProvider
tomaswolf commented on code in PR #295: URL: https://github.com/apache/mina-sshd/pull/295#discussion_r1053192599 ## sshd-sftp/src/test/java/org/apache/sshd/sftp/client/fs/SftpFileSystemTest.java: ## @@ -87,6 +89,7 @@ import org.junit.runners.MethodSorters; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import org.testcontainers.shaded.org.apache.commons.io.output.ByteArrayOutputStream; Review Comment: Wrong import. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on pull request #242: Fix: close session when timeout during connect
tomaswolf commented on PR #242: URL: https://github.com/apache/mina-sshd/pull/242#issuecomment-1359155156 I can't promise anything. All the maintainers in this project are unpaid volunteers doing this in their spare time. I wrote in October I'd be working on this, and I am, but progress depends on the amount of spare time I have and that I am willing to dedicate to this. (Evidently, I do many other things in my spare time, too.) So I can't give a deadline. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] onyas commented on pull request #242: Fix: close session when timeout during connect
onyas commented on PR #242: URL: https://github.com/apache/mina-sshd/pull/242#issuecomment-1358715900 Is there any possibility to release it early next year? our customer is eager to get this fixed. If not, can you provide any plan so that we can set the expectation for the customer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #294: Memory Leak in SftpFileSystemProvider
tomaswolf commented on issue #294: URL: https://github.com/apache/mina-sshd/issues/294#issuecomment-1358527146 Thanks for pointing out this bug. It should be fixed by the referenced pull request. But personally I'm not convinced using a ThreadLocal to store these wrappers is a good idea. It appears the idea was to use different SftpClients and thus SSH channels for different threads. I cannot be sure though since there is no design documentation and this code was written long before I became involved here. I'm not entirely sure that using ThreadLocals for this works as intended in all cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new pull request, #295: GH-294: Fix memory leaks in SftpFileSystemProvider
tomaswolf opened a new pull request, #295: URL: https://github.com/apache/mina-sshd/pull/295 SftpFileSystem.getClient() returns reference-counted wrapper instances that need to be closed to avoid a memory leak via ThreadLocals. Make sure that the streams returned by SftpFileSystemProvider.newInputStream() and newOutputStream() do close the client used by ensuring that the streams returned by SftpFileSystem.read() and write() do so. Also fix SftpFileSystemProvider.copy() to close the SftpClient it uses. SftpFileSystemProvider.newDirectoryStream() and newFileChannel() already do close the SftpClient used. Fix the SftpFileSystemTest to properly close SftpClients and DirectoryStreams. Fixes #294. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf merged pull request #292: Fix the channel window logic
tomaswolf merged PR #292: URL: https://github.com/apache/mina-sshd/pull/292 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] luchenguang commented on issue #294: Memory Leak in SftpFileSystemProvider
luchenguang commented on issue #294: URL: https://github.com/apache/mina-sshd/issues/294#issuecomment-1357686187 Meet the same question when using SftpFileSystem, seems to be caused by SftpFileSystem using a ThreadLocal to cache a sftp client but unable to clear it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] sparkchans opened a new issue, #294: Memory Leak in SftpFileSystemProvider
sparkchans opened a new issue, #294: URL: https://github.com/apache/mina-sshd/issues/294 ### Version master ### Bug description The newInputStream and newOutputStream methods of SftpFileSystemProvider call the SftpFileSystem#getClient() method without call the close() method:  ### Actual behavior I have a thread that uploads a file to the server every 10 seconds, as time goes by, the heap memory will get bigger and bigger, and eventually the heap memory will occur out of memory:  When I exported the heap memory, I found that there are a lot of objects of org.apache.sshd.sftp.client.fs.SftpFileSystem$Wrapper  ### Expected behavior When the program is running normally, the heap memory will not overflow ### Relevant log output _No response_ ### Other information _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf commented on issue #293: Performance problems in tests (NIO2, MINA, ubuntu)
tomaswolf commented on issue #293: URL: https://github.com/apache/mina-sshd/issues/293#issuecomment-1356404731 Partial problem cause: in the **SftpTransferTest**, the problem is the SFTP buffer size of 64kB in `testTransferIntegrityWithBufferLargerThanPacket`. That is 1kB more than the maximum the server will ever return; its setting for the maximum chunk to return is 63kB. This means the client fetches the missing 1kB synchronously, which makes transfer times explode to 120s when running this test locally on a CentOS 7 virtual machine, as opposed to about 14 seconds with the default SFTP buffer size. If the buffer size is 62kB, this test runs locally for me also fast in 10 seconds. I had pointed that out before in [SSHD-1287](https://issues.apache.org/jira/browse/SSHD-1287). There is clearly room for improvements there. This test is run twice during `SftpTransferTest`, and the overall run time of this test class is about 300s also locally on CentOS. This does not explain yet: * why there is no such problem on Windows, nor with Netty on Linux. (Or at least, why the time doesn't increase that much.) * why the overall time for that test increased from 120s in September to 300s in December. Some bisecting is needed. * where the far less marked but still noticeable difference in **ScpTest** comes from. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] tomaswolf opened a new issue, #293: Performance problems in tests (NIO2, MINA, ubuntu)
tomaswolf opened a new issue, #293: URL: https://github.com/apache/mina-sshd/issues/293 Looking through the GitHub build logs, there seems to be a problem with two tests on Linux, with the NIO2 or MINA transport back-ends. They show very poor performance: **org.apache.sshd.sftp.client.SftpTransferTest** ``` Build NIO2 MINA Netty ubuntu, java 8 ~300s ~300s ~70s ubuntu, java 11~300s ~300s ~50s ubuntu, java 17~300s ~300s ~50s windows, java 8 ~62s~67s ~66s windows, java 11~49s~49s ~43s windows, java 17~43s~44s ~45s ``` **org.apache.sshd.scp.client.ScpTest** ``` Build NIO2 MINA Netty ubuntu, java 8 ~19s~19s ~11s ubuntu, java 11 ~19s~19s ~11s ubuntu, java 17 ~19s~19s ~11s windows, java 8 ~12s~12s ~12s windows, java 11~12s~12s ~12s windows, java 17~12s~12s ~12s ``` These are the only tests for which I see such discrepancies. It looks like the code is doing something that doesn't play well with NIO2 or MINA on Linux. It's not a new problem either; I could find this pattern also in the [build logs of 2022-10-25](https://github.com/apache/mina-sshd/actions/runs/3318464369/jobs/5482485034) (commit 7ad3eadef) and also in even older builds. Though e.g. in a [build from 2022-09-20](https://github.com/apache/mina-sshd/actions/runs/3089979040/jobs/4998289149) the differences are smaller (but still there; 120s instead of 300s, and 15s instead of 19s). The windows times and the Linux/Netty times appear to be about normal and are what I also see for NIO2 or MINA when building locally on OS X: 12s for ScpTest and about a minute for the SftpTransferTest. What is going on here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
