Re: [I] mina-sshd How does sshClient use the ssh ControlMaster feature [mina-sshd]
tomaswolf closed issue #513: mina-sshd How does sshClient use the ssh ControlMaster feature URL: https://github.com/apache/mina-sshd/issues/513 -- 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
Re: [I] mina-sshd How does sshClient use the ssh ControlMaster feature [mina-sshd]
czldb2 commented on issue #513: URL: https://github.com/apache/mina-sshd/issues/513#issuecomment-2156276842 > ControlMaster is not implemented, and neither are ControlPath nor ControlPersist. > > Depending on your use case, you can just create a session, and then create multiple channels, as you need. Sequentially, or even in parallel. (Unless the server restricts the number of channels somehow, but then you'd also have a problem with ControlMaster connections.) Just keep the session around for as long as you need it. Possibly use heartbeats to prevent the peer from closing the session prematurely. > > If your use case involves multiple processes, you'd have to implement some mechanism akin to ControlMaster and ControlPath yourself. But note that the default NIO2 transport in Apache MINA SSHD uses `AsynchronousSocketChannel`s, which do not support using pre-existing sockets. Perhaps it might be possible to build something using the MINA or Netty transports, or by customizing those. > > (The control master would handle the SSH transport protocol including key exchanges and encryption/decryption, plus authentication, while all the clients of the master would only do the SSH connection (i.e., channel) protocol. The connections between the master and its clients are unencrypted, and thus had better be local. The two protocol layers (transport and connection) are not well separated in Apache MINA SSHD, so this might involve some serious refactoring.) Thank you very much for your reply, which is very helpful 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
Re: [I] mina-sshd How does sshClient use the ssh ControlMaster feature [mina-sshd]
tomaswolf commented on issue #513: URL: https://github.com/apache/mina-sshd/issues/513#issuecomment-2155629562 ControlMaster is not implemented, and neither are ControlPath nor ControlPersist. Depending on your use case, you can just create a session, and then create multiple channels, as you need. Sequentially, or even in parallel. (Unless the server restricts the number of channels somehow, but then you'd also have a problem with ControlMaster connections.) Just keep the session around for as long as you need it. Possibly use heartbeats to prevent the peer from closing the session prematurely. If your use case involves multiple processes, you'd have to implement some mechanism akin to ControlMaster and ControlPath yourself. But note that the default NIO2 transport in Apache MINA SSHD uses `AsynchronousSocketChannel`s, which do not support using pre-existing sockets. Perhaps it might be possible to build something using the MINA or Netty transports, or by customizing those. (The control master would handle the SSH transport protocol including key exchanges and encryption/decryption, plus authentication, while all the clients of the master would only do the SSH connection (i.e., channel) protocol. The connections between the master and its clients are unencrypted, and thus had better be local. The two protocol layers (transport and connection) are not well separated in Apache MINA SSHD, so this might involve some serious refactoring.) -- 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
Re: [I] Why add "key-strict-c-...@openssh.com" and "key-strict-s-...@openssh.com" in key Algorithms? [mina-sshd]
tomaswolf commented on issue #514: URL: https://github.com/apache/mina-sshd/issues/514#issuecomment-2155053845 This is part of the mitigation against [CVE-2023-48795](https://nvd.nist.gov/vuln/detail/CVE-2023-48795). It was introduced in 2.12.0, so I don't understand what you are writing about version 2.10.0. We're not going to remove it. Especially if you're concerned about security you should _not_ remove 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
Re: [I] Why add "key-strict-c-...@openssh.com" and "key-strict-s-...@openssh.com" in key Algorithms? [mina-sshd]
tomaswolf closed issue #514: Why add "key-strict-c-...@openssh.com" and "key-strict-s-...@openssh.com" in key Algorithms? URL: https://github.com/apache/mina-sshd/issues/514 -- 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
[I] Why add "key-strict-c-...@openssh.com" and "key-strict-s-...@openssh.com" in key Algorithms? [mina-sshd]
zhyde2010 opened a new issue, #514:
URL: https://github.com/apache/mina-sshd/issues/514
### Version
2.10.0
### Bug description
We use this software. We have high requirements on algorithm security and
specially adjust the algorithm. Actually, we find that
"key-strict-c-...@openssh.com is added after the selected algorithm by default.
We think we've developed the algorithm, so we don't want to add it to us.
### Actual behavior
No matter how we set the key exchange algorithm,
key-strict-c-...@openssh.com is appended at the end.
### Expected behavior
Do not automatically add key-strict-c-...@openssh.com, or set the algorithm
to the user's choice whether to add key-strict-c-...@openssh.com.
### Relevant log output
```Shell
mina-sshd/sshd-common/src/main/java/org/apache/sshd/common/kex/extension
/KexExtensions.java:
public static final String STRICT_KEX_CLIENT_EXTENSION =
"kex-strict-c-...@openssh.com";
public static final String STRICT_KEX_SERVER_EXTENSION =
"kex-strict-s-...@openssh.com";
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
@Override
protected String resolveSessionKexProposal(String hostKeyTypes) throws
IOException {
String proposal = super.resolveSessionKexProposal(hostKeyTypes);
// see https://tools.ietf.org/html/rfc8308
KexExtensionHandler extHandler = getKexExtensionHandler();
if ((extHandler == null) ||
(!extHandler.isKexExtensionsAvailable(this, AvailabilityPhase.PROPOSAL))) {
return proposal;
}
String extType = isServerSession() ?
KexExtensions.SERVER_KEX_EXTENSION : KexExtensions.CLIENT_KEX_EXTENSION;
if (GenericUtils.isEmpty(proposal)) {
return extType;
} else {
return proposal + "," + extType;
}
```
### Other information
NA
--
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
Re: [I] SSH Client Disconnects on Receiving Keepalive Requests [mina-sshd]
ruanwenjun commented on issue #482:
URL: https://github.com/apache/mina-sshd/issues/482#issuecomment-2153752493
@coderZoe @tomaswolf Hi, I meet a problem related to the ssh keepalive.
My task failed seems due to the ssh channel closed, I am not sure if this is
due to the heartbeat miss.
```
exceptionCaught(ClientSessionImpl[cebwmapp@/10.227.23.69:16022])[state=Opened]
IOException: Connection reset by peer
```
My code is look like below
```
SshClient sshClient = SshClient.setUpDefaultClient();
sshClient.start();
ClientSession session = sshClient.connect(
sshConnectionParam.getUsername(),
sshConnectionParam.getHost(),
sshConnectionParam.getPort()).verify(timeout).getSession();
String password = sshConnectionParam.getPassword();
if (StringUtils.isNotEmpty(password)) {
session.addPasswordIdentity(password);
}
String privateKey = sshConnectionParam.getPrivateKey();
if (StringUtils.isNotEmpty(privateKey)) {
KeyPairResourceLoader loader = SecurityUtils.getKeyPairResourceParser();
Collection keyPairCollection = loader.loadKeyPairs(null, null,
null, privateKey);
for (KeyPair keyPair : keyPairCollection) {
session.addPublicKeyIdentity(keyPair);
}
}
if (!session.auth().verify(Duration.ofSeconds(timeout)).isSuccess()) {
throw new RuntimeException("Session auth failed");
}
session.setSessionHeartbeat(SessionHeartbeatController.HeartbeatType.IGNORE,
Duration.ofSeconds(PropertyUtils.getInt("session-connection-heartbeat-interval",
5)));
return session;
```
Do I need to add KeepAliveHandler.INSTANCE in globalRequestHandlers to avoid
this?
--
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
[I] mina-sshd How does sshClient use the ssh ControlMaster feature [mina-sshd]
czldb2 opened a new issue, #513: URL: https://github.com/apache/mina-sshd/issues/513  My program uses sshClient to create a ChannelExec to do things like :"ssh user@ip cmd". I now want to reuse this connection so that I don't have to re-establish the ssh connection the next time I execute "ssh user@ip cmd". How do I achieve this? -- 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
Re: [PR] Make the proxy jump resolver a bit more flexible. [mina-sshd]
tomaswolf closed pull request #477: Make the proxy jump resolver a bit more flexible. URL: https://github.com/apache/mina-sshd/pull/477 -- 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
Re: [PR] Make the proxy jump resolver a bit more flexible. [mina-sshd]
tomaswolf commented on PR #477: URL: https://github.com/apache/mina-sshd/pull/477#issuecomment-2143923600 Fixed differently via PR #512 (including tests). -- 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
Re: [PR] GH-318: fix proxyJumps [mina-sshd]
tomaswolf merged PR #512: URL: https://github.com/apache/mina-sshd/pull/512 -- 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
Re: [I] Support for more than one jump host [mina-sshd]
tomaswolf closed issue #318: Support for more than one jump host URL: https://github.com/apache/mina-sshd/issues/318 -- 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
[PR] GH-318: fix proxyJumps [mina-sshd]
tomaswolf opened a new pull request, #512: URL: https://github.com/apache/mina-sshd/pull/512 Previous code only parsed the proxy jumps of the initial HostConfigEntry. However, if the last entry in that list has a HostConfigEntry that again has proxy jumps, these additional proxies must be added to the list. And so on. To guard against proxy cascades with loops we limit the total number of proxies to at most 10. The limit is configurable through property CoreModuleProperties.MAX_PROXY_JUMPS. Fixes #318. -- 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
Re: [I] Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作 [mina-sshd]
tomaswolf closed issue #312: Connect to server failed when get session:error: 在一个非套接字上尝试了一个操作 URL: https://github.com/apache/mina-sshd/issues/312 -- 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
Re: [I] how to modifying the owner attribute of files and directories uploaded to the Linux system bye mina-sshd sftp-server [mina-sshd]
tomaswolf closed issue #503: how to modifying the owner attribute of files and directories uploaded to the Linux system bye mina-sshd sftp-server URL: https://github.com/apache/mina-sshd/issues/503 -- 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
Re: [I] How to implement SFTP resuming transfer using mina-sshd? [mina-sshd]
tomaswolf closed issue #447: How to implement SFTP resuming transfer using mina-sshd? URL: https://github.com/apache/mina-sshd/issues/447 -- 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
Re: [I] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf commented on issue #510: URL: https://github.com/apache/mina-sshd/issues/510#issuecomment-2142665312 PR was merged as commit 82e0ed1f. -- 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
Re: [I] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf closed issue #510: Fix mina full class name in BuiltinIoServiceFactoryFactories URL: https://github.com/apache/mina-sshd/issues/510 -- 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
Re: [PR] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf commented on PR #511: URL: https://github.com/apache/mina-sshd/pull/511#issuecomment-2142664561 Merged as commit 82e0ed1f. -- 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
Re: [PR] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf closed pull request #511: Fix mina full class name in BuiltinIoServiceFactoryFactories URL: https://github.com/apache/mina-sshd/pull/511 -- 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
Re: [PR] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
JinHeap commented on PR #511: URL: https://github.com/apache/mina-sshd/pull/511#issuecomment-2141078742 thanks. then if need me do something, please tell 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
Re: [PR] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf commented on PR #511: URL: https://github.com/apache/mina-sshd/pull/511#issuecomment-2140908858 Thanks. The change is good, but now that this is fixed `DefaultIoServiceFactoryFactoryTest` hangs for MINA during disposal of the partially set up (with mocks) `MinaServiceFactory`. Previously it just skipped the non-existing class. Also, `BuiltinIoServiceFactoryFactoriesTest` should have a test that fails if one of the enum constants has a wrong class name. I.e., a test that would have uncovered the original problem (wrong string). I'll see if I can amend this commit to fix these test issues. -- 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
[PR] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
JinHeap opened a new pull request, #511: URL: https://github.com/apache/mina-sshd/pull/511 Addresses https://github.com/apache/mina-sshd/issues/510 -- 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
Re: [I] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
JinHeap commented on issue #510: URL: https://github.com/apache/mina-sshd/issues/510#issuecomment-2138824207 > Looks like an obvious bug. Probably this was missed in some earlier refactoring. Want to provide a PR? OK -- 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
Re: [I] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
tomaswolf commented on issue #510: URL: https://github.com/apache/mina-sshd/issues/510#issuecomment-2138815644 Looks like an obvious bug. Probably this was missed in some earlier refactoring. 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
[I] Fix mina full class name in BuiltinIoServiceFactoryFactories [mina-sshd]
JinHeap opened a new issue, #510: URL: https://github.com/apache/mina-sshd/issues/510 https://github.com/apache/mina-sshd/blob/37d239e792edabe2008df8e98bf00eef167a147f/sshd-core/src/main/java/org/apache/sshd/common/io/BuiltinIoServiceFactoryFactories.java#L37 full class name in BuiltinIoServiceFactoryFactories for mina is unavailable. I have to modified the code from org.apache.sshd.common.io.mina.MinaServiceFactoryFactory to org.apache.sshd.mina.MinaServiceFactoryFactory in order to run SshClientMain with mina > java -cp * org.apache.sshd.cli.client.SshClientMain -w 1 root@127.0.0.1 -io mina SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.sshd.common.io.mina.MinaServiceFactoryFactory at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.getFactoryClass(BuiltinIoServiceFactoryFactories.java:76) at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.create(BuiltinIoServiceFactoryFactories.java:88) at org.apache.sshd.cli.CliSupport.setupIoServiceFactory(CliSupport.java:149) at org.apache.sshd.cli.client.SshClientCliSupport.setupDefaultClient(SshClientCliSupport.java:407) at org.apache.sshd.cli.client.SshClientCliSupport.setupClient(SshClientCliSupport.java:447) at org.apache.sshd.cli.client.SshClientCliSupport.setupClientSession(SshClientCliSupport.java:244) at org.apache.sshd.cli.client.SshClientMain.main(SshClientMain.java:134) Caused by: java.lang.ClassNotFoundException: org.apache.sshd.common.io.mina.MinaServiceFactoryFactory at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.getFactoryClass(BuiltinIoServiceFactoryFactories.java:71) ... 6 more Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.sshd.common.io.mina.MinaServiceFactoryFactory at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.getFactoryClass(BuiltinIoServiceFactoryFactories.java:76) at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.create(BuiltinIoServiceFactoryFactories.java:88) at org.apache.sshd.cli.CliSupport.setupIoServiceFactory(CliSupport.java:149) at org.apache.sshd.cli.client.SshClientCliSupport.setupDefaultClient(SshClientCliSupport.java:407) at org.apache.sshd.cli.client.SshClientCliSupport.setupClient(SshClientCliSupport.java:447) at org.apache.sshd.cli.client.SshClientCliSupport.setupClientSession(SshClientCliSupport.java:244) at org.apache.sshd.cli.client.SshClientMain.main(SshClientMain.java:134) Caused by: java.lang.ClassNotFoundException: org.apache.sshd.common.io.mina.MinaServiceFactoryFactory at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.sshd.common.io.BuiltinIoServiceFactoryFactories.getFactoryClass(BuiltinIoServiceFactoryFactories.java:71) ... 6 more -- 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
Re: [I] OsUtils#isAndroid() returns false on WearOS [mina-sshd]
tomaswolf closed issue #499: OsUtils#isAndroid() returns false on WearOS URL: https://github.com/apache/mina-sshd/issues/499 -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2137696332 Done in commit 37d239e. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf closed issue #509: BufferException: Underflow error URL: https://github.com/apache/mina-sshd/issues/509 -- 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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on PR #507: URL: https://github.com/apache/mina-sshd/pull/507#issuecomment-2137589316 Thanks for the 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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf merged PR #507: URL: https://github.com/apache/mina-sshd/pull/507 -- 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
Re: [I] heartbeat timeout of a session will cause the links of other sessions to be disconnected [mina-sshd]
tomaswolf closed issue #461: heartbeat timeout of a session will cause the links of other sessions to be disconnected URL: https://github.com/apache/mina-sshd/issues/461 -- 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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on PR #507: URL: https://github.com/apache/mina-sshd/pull/507#issuecomment-2136694291 Also in the newest change: when TIMEOUT is explicitly set <= 0 and NO_RELY_MAX is not set, set NO_REPLY_MAX to zero. -- 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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1618319934
##
CHANGES.md:
##
@@ -58,7 +59,39 @@ NTRU Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512](https://ww
## Behavioral changes and enhancements
-* [GH-468](https://github.com/apache/mina-sshd/issues/468) SFTP: validate
length of data received: must not be more than requested
+### [GH-461](https://github.com/apache/mina-sshd/issues/461) Fix heartbeats
with `wantReply=true`
+
+The client-side heartbeat mechanism has been updated. Such heartbeats are
configured via the
+`CoreModuleProperties.HEARTBEAT_INTERVAL` property. If this interval is > 0,
heartbeats are sent to
+the server.
+
+Previously these heartbeats could also be configured with a
`CoreModuleProperties.HEARTBEAT_REPLY_WAIT`
+timeout. If the timeout was <= 0, the client would just send heartbeat
requests without expecting any
+answers. If the timeout was > 0, the client would send requests with a flag
indicating that the server
+should reply. The client would then wait for the specified duration for the
reply and would terminate
+the connection if none was received.
+
+This old mechanism could cause trouble if the timeout was fairly long and the
server was slow to respond.
Review Comment:
Done.
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,41 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new
no-reply-max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the previous system,
that would have killed the session when
+// the
Review Comment:
Done.
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
gnodet commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617916399
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,41 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new
no-reply-max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the previous system,
that would have killed the session when
+// the
Review Comment:
This should be reformatted to avoid a single word on a line.
##
CHANGES.md:
##
@@ -58,7 +59,39 @@ NTRU Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512](https://ww
## Behavioral changes and enhancements
-* [GH-468](https://github.com/apache/mina-sshd/issues/468) SFTP: validate
length of data received: must not be more than requested
+### [GH-461](https://github.com/apache/mina-sshd/issues/461) Fix heartbeats
with `wantReply=true`
+
+The client-side heartbeat mechanism has been updated. Such heartbeats are
configured via the
+`CoreModuleProperties.HEARTBEAT_INTERVAL` property. If this interval is > 0,
heartbeats are sent to
+the server.
+
+Previously these heartbeats could also be configured with a
`CoreModuleProperties.HEARTBEAT_REPLY_WAIT`
+timeout. If the timeout was <= 0, the client would just send heartbeat
requests without expecting any
+answers. If the timeout was > 0, the client would send requests with a flag
indicating that the server
+should reply. The client would then wait for the specified duration for the
reply and would terminate
+the connection if none was received.
+
+This old mechanism could cause trouble if the timeout was fairly long and the
server was slow to respond.
Review Comment:
Remove `old`
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507: URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617835398 ## CHANGES.md: ## @@ -58,7 +59,34 @@ NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512](https://ww ## Behavioral changes and enhancements -* [GH-468](https://github.com/apache/mina-sshd/issues/468) SFTP: validate length of data received: must not be more than requested +### [GH-461](https://github.com/apache/mina-sshd/issues/461) Fix heartbeats with `wantReply=true` + +The client-side heartbeat mechanism has been changed. Such heartbeats are configured with an interval +(`CoreModuleProperties.HEARTBEAT_INTERVAL`) > 0. Previously they could also be configured with a timeout +(`CoreModuleProperties.HEARTBEAT_REPLY_WAIT`). If the timeout was <= 0, the client would just send a +heartbeat request, but not expect any answer. However, with a timeout > 0, it would send the request +with a flag telling the server to send back a reply, and then wait for the given duration for the +reply to arrive, and terminate the connection if no reply was forthcoming. + +That could cause trouble if the timeout was fairly long, and the server was slow to respond. If the +timeout was longer than the interval it could also delay subsequent heartbeats. + +Newly, `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` is _deprecated_. There is a new configuration property +`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` instead. It defines a limit for how many heartbeats without +reply a session survives. If the value is <= 0, the client still sends heartbeats without expecting +any answer. If > 0, it will request a reply from the server for each heartbeat message, and it will +terminate the connection once there are `CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` previous heartbeats +for which no reply was received yet. + +This new way to configure heartbeats corresponds to the configuration in OpenSSH via the +`ServerAliveInterval` and `ServerAliveCountMax` options. + +For compatibility with old configurations that do define `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` > 0, +the new code maps this to the new configuration (but only if `CoreModuleProperties.HEARTBEAT_INTERVAL` > 0 +and the new property `CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX` has _not_ been set) by setting +`CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX = (CoreModuleProperties.HEARTBEAT_REPLY_WAIT / CoreModuleProperties.HEARTBEAT_INTERVAL) + 1`. Review Comment: Done. I've taken this as inspiration and have rephrased the description along these lines. -- 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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617834559
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
Review Comment:
Done.
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617834382
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the old system, that
would have killed the session when the
+// timeout was reached. A slow server that managed to return the
reply just before the timeout expired would
+// have delayed subsequent heartbeats. The new system will keep
sending heartbeats with the given interval.
+// Thus we can have timeout / interval heartbeats without reply if
we want to approximate the old system.
+double timeoutSec = timeout.getSeconds() + (timeout.getNano() /
1_000_000_000.0);
+double intervalSec = heartbeatInterval.getSeconds() +
(heartbeatInterval.getNano() / 1_000_000_000.0);
+double multiple = timeoutSec / intervalSec;
+if (multiple >= Integer.MAX_VALUE - 1) {
+return Integer.MAX_VALUE;
+} else {
+return (int) multiple + 1;
+}
+}
+// Timeout is smaller than the interval. We want to have every
heartbeat replied to.
+return 1;
+// This is an approximation. If no reply is forthcoming, the session
will newly be killed after the interval. In
Review Comment:
Done.
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the old system, that
would have killed the session when the
Review Comment:
Done.
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617834119
##
sshd-core/src/main/java/org/apache/sshd/core/CoreModuleProperties.java:
##
@@ -162,10 +162,21 @@ public final class CoreModuleProperties {
/**
* Key used to indicate that the heartbeat request is also expecting a
reply - time in milliseconds to wait
* for the reply. If non-positive then no reply is expected (nor
requested).
+ *
+ * @deprecated since 2.13.0, use {@link #HEARTBEAT_NO_REPLY_MAX} instead
*/
+@Deprecated
Review Comment:
The since property does not exist in Java 8. It was introduced in Java 9.
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the old system, that
would have killed the session when the
+// timeout was reached. A slow server that managed to return the
reply just before the timeout expired would
+// have delayed subsequent heartbeats. The new system will keep
sending heartbeats with the given interval.
+// Thus we can have timeout / interval heartbeats without reply if
we want to approximate the old system.
+double timeoutSec = timeout.getSeconds() + (timeout.getNano() /
1_000_000_000.0);
+double intervalSec = heartbeatInterval.getSeconds() +
(heartbeatInterval.getNano() / 1_000_000_000.0);
+double multiple = timeoutSec / intervalSec;
+if (multiple >= Integer.MAX_VALUE - 1) {
+return Integer.MAX_VALUE;
+} else {
+return (int) multiple + 1;
+}
+}
+// Timeout is smaller than the interval. We want to have every
heartbeat replied to.
+return 1;
+// This is an approximation. If no reply is forthcoming, the session
will newly be killed after the interval. In
+// the old system it would have been killed after the timeout. We
_could_ code something to schedule a task that
Review Comment:
Done.
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617833708
##
sshd-core/src/main/java/org/apache/sshd/core/CoreModuleProperties.java:
##
@@ -162,10 +162,21 @@ public final class CoreModuleProperties {
/**
* Key used to indicate that the heartbeat request is also expecting a
reply - time in milliseconds to wait
* for the reply. If non-positive then no reply is expected (nor
requested).
+ *
+ * @deprecated since 2.13.0, use {@link #HEARTBEAT_NO_REPLY_MAX} instead
*/
+@Deprecated
public static final Property HEARTBEAT_REPLY_WAIT
= Property.durationSec("heartbeat-reply-wait",
Duration.ofMinutes(5));
+/**
+ * Key to set the maximum number of heartbeat messages to send without
having received a reply. If 0, heartbeat
+ * messages are sent with a flag that requires the peer to reply. The
session will be killed if
+ * {@code HEARTBEAT_NO_REPLY_MAX} heartbeats have been sent without having
received a reply. If = 0, heartbeat
+ * messages will be sent, but no reply is requested or expected, and the
client will not kill the session.
+ */
Review Comment:
Done.
--
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
Re: [PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
gnodet commented on code in PR #507:
URL: https://github.com/apache/mina-sshd/pull/507#discussion_r1617742237
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
+// set it from the timeout.
+Integer noReplyValue =
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getOrNull(this);
+if (noReplyValue != null) {
+return noReplyValue.intValue();
+}
+if (timeout.compareTo(heartbeatInterval) >= 0) {
+// Timeout is longer than the interval. With the old system, that
would have killed the session when the
+// timeout was reached. A slow server that managed to return the
reply just before the timeout expired would
+// have delayed subsequent heartbeats. The new system will keep
sending heartbeats with the given interval.
+// Thus we can have timeout / interval heartbeats without reply if
we want to approximate the old system.
+double timeoutSec = timeout.getSeconds() + (timeout.getNano() /
1_000_000_000.0);
+double intervalSec = heartbeatInterval.getSeconds() +
(heartbeatInterval.getNano() / 1_000_000_000.0);
+double multiple = timeoutSec / intervalSec;
+if (multiple >= Integer.MAX_VALUE - 1) {
+return Integer.MAX_VALUE;
+} else {
+return (int) multiple + 1;
+}
+}
+// Timeout is smaller than the interval. We want to have every
heartbeat replied to.
+return 1;
+// This is an approximation. If no reply is forthcoming, the session
will newly be killed after the interval. In
Review Comment:
newly -> immediately ?
##
sshd-core/src/main/java/org/apache/sshd/client/session/ClientConnectionService.java:
##
@@ -55,7 +61,40 @@ public ClientConnectionService(AbstractClientSession s)
throws SshException {
heartbeatRequest =
CoreModuleProperties.HEARTBEAT_REQUEST.getRequired(this);
heartbeatInterval =
CoreModuleProperties.HEARTBEAT_INTERVAL.getRequired(this);
-heartbeatReplyMaxWait =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getRequired(this);
+heartbeatMaxNoReply = configureMaxNoReply();
+}
+
+protected int configureMaxNoReply() {
+@SuppressWarnings("deprecation")
+Duration timeout =
CoreModuleProperties.HEARTBEAT_REPLY_WAIT.getOrNull(this);
+if (timeout == null ||
GenericUtils.isNegativeOrNull(heartbeatInterval) ||
GenericUtils.isEmpty(heartbeatRequest)) {
+return
CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX.getRequired(this).intValue();
+}
+// The deprecated timeout is configured explicitly. If the new no
reply max is _not_ explicitly configured,
Review Comment:
"no reply max" -> "no-reply-max" so that it's easier to see we're referring
to the value
##
sshd-core/src/main/java/org/apache/sshd/core/CoreModuleProperties.java:
##
@@ -162,10 +162,21 @@ public final class CoreModuleProperties {
/**
* Key used to indicate that the heartbeat request is also expecting a
reply - time in milliseconds to wait
* for the reply. If non-positive then no reply is expected (nor
requested).
+ *
+ * @deprecated since 2.13.0, use {@link #HEARTBEAT_NO_REPLY_MAX} instead
*/
+@Deprecated
public static final Property HEARTBEAT_REPLY_WAIT
= Property.durationSec("heartbeat-reply-wait",
Duration.ofMinutes(5));
+/**
+ * Key to set the maximum number of heartbeat messages to send without
having received a reply. If 0, heartbeat
+ * messages are sent with a flag that requires the peer to reply. The
session will be killed if
+ * {@code HEARTBEAT_NO_REPLY_MAX} heartbeats have been sent without having
received a reply. If = 0, heartbeat
+ * messages will be sent, but no reply is requested or expected, and the
client will not kill the session.
+ */
Review Comment:
`@since 2.13.0`
Re: [I] heartbeat timeout of a session will cause the links of other sessions to be disconnected [mina-sshd]
tomaswolf commented on issue #461: URL: https://github.com/apache/mina-sshd/issues/461#issuecomment-2135764945 Any comments on the PR #507? If none, I'll assume it's fine and will merge tomorrow. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2134655636 There is a minor bug in Apache MINA sshd, though: when we request file attributes, we tell the server we're interested in all items: https://github.com/apache/mina-sshd/blob/5a78e6dfe37ec982de8eec7abf449e83b3c984ae/sshd-sftp/src/main/java/org/apache/sshd/sftp/client/impl/AbstractSftpClient.java#L1027-L1029 This sends 0x00_00_FF_FF. But this is not correct. In SFTP >= v4, bit 0x2 MUST NOT be set: > 0x0002 MUST NOT appear in the mask. [draft RFC](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-03#section-5.1) Therefore re-opening to fix this. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2134637164 BTW: this is https://github.com/proftpd/proftpd/issues/578 . Was fixed in proftpd [version 1.3.7rc1](https://github.com/proftpd/proftpd/blob/fb6bd090542ee432096df5b136f1b14ec639928e/NEWS#L419) in October 2019. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
nimantha-lakshan commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2134501632 I'll close the issue -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
nimantha-lakshan closed issue #509: BufferException: Underflow error URL: https://github.com/apache/mina-sshd/issues/509 -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
nimantha-lakshan commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2134499472 I'm sorry for just attaching a screenshot. This is our internal SFTP server (ProFTPD), which is old. I'll let our team know about this. I managed to avoid the exception by using SFTP version 3 in the client. Thank you very much for your help. -- 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
Re: [I] Can I design a ssh server with sshd? [mina-sshd]
tomaswolf closed issue #496: Can I design a ssh server with sshd? URL: https://github.com/apache/mina-sshd/issues/496 -- 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
Re: [I] Can I design a ssh server with sshd? [mina-sshd]
tomaswolf commented on issue #496: URL: https://github.com/apache/mina-sshd/issues/496#issuecomment-2134025276 Use the latest. -- 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
Re: [I] how to modifying the owner attribute of files and directories uploaded to the Linux system bye mina-sshd sftp-server [mina-sshd]
tomaswolf commented on issue #503: URL: https://github.com/apache/mina-sshd/issues/503#issuecomment-2134024573 Apache MINA SSHD is a Java library and has no integration with the Linux user management, and it does not have privilege separation either. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2133926998 Next time please provide the buffer content as copyable text. A screenshot is extremely cumbersome to work with. What server is this? It appears to be broken. If I parse this buffer content as an SFTP v6 SSH_FXP_ATTR packet, I cannot match it against the [draft RFC](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-7). - 0 0 0 69 Length of following data - 105 SSH_FXP_ATTR - 0 0 0 102 Request ID. - 0 0 -1 -1 Flags. hex 0x00_00_FF_FF. Strange that all bits are set. In particular, 0x2 should not occur. - 2 File type; 2 is a directory - 0 0 0 0 0 0 16 0 File size, 0x1000 = 4096 bytes - And now things go wrong: because bit 0x400 is set in the flags, we read the next 8 bytes as "allocation size", but its not present. Instead the buffer continues with - 0 0 0 11 Length of the string following (11 bytes, apparently owner name) - 105 116 101 115 99 111 95 114 111 111 116 = "itesco_root" - 0 0 0 8 String length - 102 116 112 103 114 111 117 112 = "ftpgroup" - ... Because we read an allocation size (due to the wrong flags), we skip 8 bytes and end up reading some of the characters (bytes 99 111 95 114, hex 0x63_6F_5F_72) as a string length, and then the exception occurs. What server is this? It is broken; it sends invalid flags. We cannot do anything about this in the client side. File a bug report against that server, and try to avoid using SFTP v6 for that server: force SFTP v3. -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
nimantha-lakshan commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2133819934 SFTP protocol version: 6  -- 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
Re: [I] BufferException: Underflow error [mina-sshd]
tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2133722091 Which servers? Which SFTP protocol version? Use debug or trace logging to capture the content of the response to the STAT request, then provide the log. (Or run the client with a debug breakpoint in `AbstractSftpClient.readAttributes()` and post the buffer contents as shown in the debugger.) -- 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
[I] BufferException: Underflow error [mina-sshd]
nimantha-lakshan opened a new issue, #509:
URL: https://github.com/apache/mina-sshd/issues/509
### Version
2.12.1
### Bug description
```java
Caused by: org.apache.sshd.common.util.buffer.BufferException: Underflow:
requested=1668243314, available=39
at
org.apache.sshd.common.util.buffer.Buffer.ensureAvailable(Buffer.java:661)
~[sshd-common-2.12.1.jar:2.12.1]
at
org.apache.sshd.common.util.buffer.ByteArrayBuffer.getString(ByteArrayBuffer.java:241)
~[sshd-common-2.12.1.jar:2.12.1]
at org.apache.sshd.common.util.buffer.Buffer.getString(Buffer.java:332)
~[sshd-common-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.readAttributes(AbstractSftpClient.java:439)
~[sshd-sftp-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.checkAttributesResponse(AbstractSftpClient.java:331)
~[sshd-sftp-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.checkAttributes(AbstractSftpClient.java:325)
~[sshd-sftp-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.stat(AbstractSftpClient.java:990)
~[sshd-sftp-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.fs.SftpClientDirectoryScanner.scan(SftpClientDirectoryScanner.java:125)
~[sshd-sftp-2.12.1.jar:2.12.1]
at
org.apache.sshd.sftp.client.fs.SftpClientDirectoryScanner.scan(SftpClientDirectoryScanner.java:115)
~[sshd-sftp-2.12.1.jar:2.12.1]
```
code example:
```java
private void process(String host, int port, String username, String
password, String homePath) throws IOException {
try (SshClient sshClient = SshClient.setUpDefaultClient()) {
sshClient.setServerKeyVerifier(AcceptAllServerKeyVerifier.INSTANCE);
sshClient.setHostConfigEntryResolver(HostConfigEntryResolver.EMPTY);
sshClient.setKeyIdentityProvider(KeyIdentityProvider.EMPTY_KEYS_PROVIDER);
sshClient.start();
// Connect to the SFTP server
try (ClientSession session = sshClient.connect(username, host,
port).verify(Duration.ofSeconds(30)).getSession()) {
session.addPasswordIdentity(password);
log.info("Connected to {}:{}. Authenticating...", host,
port);
var verify = session.auth().verify(Duration.ofSeconds(30));
log.info("Authentication {}", verify.isSuccess() ? "success"
: "failure");
try (SftpClient sftpClient =
SftpClientFactory.instance().createSftpClient(session)) {
var directoryScanner = new
SftpClientDirectoryScanner(homePath, "*.csv");
directoryScanner.setCaseSensitive(false);
var scan = directoryScanner.scan(sftpClient); // throws
error from here
}
}
}
}
```
### Actual behavior
SFTP client not working as expected.
I'm receiving this error
`org.apache.sshd.common.util.buffer.BufferException: Underflow:
requested=1668243314, available=39`
This happens only with some SFTP servers.
### Expected behavior
To resolve this 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
Re: [I] Can port forwarding be maintained? Currently, it is closed immediately after forwarding. [mina-sshd]
hengboy closed issue #508: Can port forwarding be maintained? Currently, it is closed immediately after forwarding. URL: https://github.com/apache/mina-sshd/issues/508 -- 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
Re: [I] Can port forwarding be maintained? Currently, it is closed immediately after forwarding. [mina-sshd]
hengboy commented on issue #508: URL: https://github.com/apache/mina-sshd/issues/508#issuecomment-2132941454 @tomaswolf Thank you very much, the problem is solved -- 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
Re: [I] Can port forwarding be maintained? Currently, it is closed immediately after forwarding. [mina-sshd]
hengboy commented on issue #508: URL: https://github.com/apache/mina-sshd/issues/508#issuecomment-2132926938 @tomaswolf ClientSession#close method not called -- 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
Re: [I] Can port forwarding be maintained? Currently, it is closed immediately after forwarding. [mina-sshd]
tomaswolf commented on issue #508: URL: https://github.com/apache/mina-sshd/issues/508#issuecomment-2132825956 You close the SshClient, which closes the session. -- 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
[I] Can port forwarding be maintained? Currently, it is closed immediately after forwarding. [mina-sshd]
hengboy opened a new issue, #508:
URL: https://github.com/apache/mina-sshd/issues/508
### Version
2.12.2
### Bug description
```java
try (SshClient client = SshClient.setUpDefaultClient()) {
client.start();
clientSession = client.connect(config.getUsername(),
config.getServerIp(), config.getSshPort()).verify().getSession();
boolean result = clientSession.auth().verify().await();
if (!result) {
throw new AgentException("Remote server ssh login failed.");
} else {
log.info("Connection to the remote server [{}] is
successful.", config.getServerIp());
// Local and remote port number binding forwarding
this.portForwardingTracker =
clientSession.createLocalPortForwardingTracker(new
SshdSocketAddress(FORWARD_LOCAL_IP, config.getLocalPort()),
new SshdSocketAddress(config.getForwardTargetIp(),
config.getForwardTargetPort()));
log.info("Port forwarding binding is completed, local port :
{}, forward IP: {}, forward port : {}",
config.getLocalPort(), config.getForwardTargetIp(),
config.getForwardTargetPort());
}
} catch (Exception e) {
throw new AgentException("Remote server port number forwarding
failed.", e);
}
```
### Actual behavior
sshd logs
```
May 27 06:37:35 node1 sshd[1367281]: Accepted publickey for root from
xxx.xxx.xx port 51881 ssh2: ED25519 SHA256:k0velrxirD8HY9rq/GMBqoBI..
May 27 06:37:35 node1 sshd[1367281]: pam_unix(sshd:session): session opened
for user root(uid=0) by (uid=0)
May 27 06:37:35 node1 systemd-logind[743]: New session 244 of user root.
May 27 06:37:35 node1 sshd[1367281]: pam_unix(sshd:session): session closed
for user root
May 27 06:37:35 node1 systemd-logind[743]: Session 244 logged out. Waiting
for processes to exit.
May 27 06:37:35 node1 systemd-logind[743]: Removed session 244.
```
### Expected behavior
If the close method is not executed, the forwarding will continue.
### 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
[PR] GH-461: Fix heartbeats with wantReply=true [mina-sshd]
tomaswolf opened a new pull request, #507: URL: https://github.com/apache/mina-sshd/pull/507 Switch from a timeout model to the OpenSSH model: fail if there are more than a certain number of heartbeats for which no reply was received yet. Fixes #461. -- 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
Re: [I] SFTP client does not work after it just worked [mina-sshd]
tomaswolf commented on issue #506: URL: https://github.com/apache/mina-sshd/issues/506#issuecomment-2128703009 We're not here to debug your code. Debug your `namespace.data.transfer.SFTPDataTransferService` in isolation. Perhaps the wrong key is used. -- 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
Re: [I] SFTP client does not work after it just worked [mina-sshd]
tomaswolf closed issue #506: SFTP client does not work after it just worked URL: https://github.com/apache/mina-sshd/issues/506 -- 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
[I] SFTP client does not work after it just worked [mina-sshd]
liugongjian opened a new issue, #506:
URL: https://github.com/apache/mina-sshd/issues/506
### Version
2.12.1
### Bug description
Those code below is my demo code. It works fine on local enviroment. But it
does not work after deployed to remote server. The log output is shown below.
But oddly, after restart the server, it works with no exceptions. And a
period later（ussally after when another user logged in and try to upload file
to sftp with this）, it does not work with error log outputted again.
Enviroment:
jdk 1.8
resin 4.0.66
Ubuntu 24.04 LTS
```
public void connect() throws IOException {
//Security.removeProvider("BC");
SshClient client = SshClient.setUpDefaultClient();
FileKeyPairProvider keyPairProvider = new
FileKeyPairProvider(Paths.get(privateKeyPath));
client.setKeyIdentityProvider(keyPairProvider);
client.start();
System.out.println("add key to session only with try");
ClientSession session =
client.connect(login,server,port).verify().getSession();
session.auth().verify();
//session.setKeyIdentityProvider(keyPairProvider);
this.session = session;
this.client = client;
}
public void uploadFile(String sourceFile, String destinationFile) throws
IOException {
try {
SftpClient sftpClient =
SftpClientFactory.instance().createSftpClient(session);
File tmpFile = new File(sourceFile);
String fileName = tmpFile.getName();
String destinationFilePath = destinationFile.endsWith("/") ?
destinationFile + fileName : destinationFile + "/" + fileName;
SftpClient.Handle handle = sftpClient.open(destinationFilePath,
EnumSet.of(SftpClient.OpenMode.Write, SftpClient.OpenMode.Create));
String fileData = new
String(Files.readAllBytes(Paths.get(sourceFile)));;
sftpClient.write(handle, 0, fileData.getBytes(), 0,
fileData.length());
sftpClient.close(handle);
sftpClient.close();
if(session.isOpen()){
session.close(true);
}
if(client.isOpen()){
client.close();
}
} catch (IOException e) {
throw e;
}
}
```
And after every transfer task, I disconnect as below:
```
public void disconnect() throws IOException {
if (c != null) {
c.disconnect();
}
if (channel != null) {
channel.disconnect();
}
if (session != null) {
session.disconnect(0,"");
session.close(true);
session = null;
}
if(client != null) {
client.stop();
client.close();
client = null;
}
}
```
### Actual behavior
not function well
### Expected behavior
function well
### Relevant log output
```Shell
org.apache.sshd.common.SshException: No more authentication methods available
at
org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:141)
~[sshd-common-2.12.1.jar:2.12.1]
at
org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:56)
~[sshd-core-2.12.1.jar:2.12.1]
at
org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:35)
~[sshd-core-2.12.1.jar:2.12.1]
at
org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:43)
~[sshd-common-2.12.1.jar:2.12.1]
at
cx.cocca.utils.SFTPClient.connect(SFTPClient.java:133) ~[classes:?]
at
cx.cocca.registry.data.transfer.SFTPDataTransferService.testConnection(SFTPDataTransferService.java:31)
[classes:?]
at
cx.cocca.registry.maintenance.EscrowFileUploader.testConnection(EscrowFileUploader.java:82)
[classes:?]
at
cx.cocca.registry.maintenance.ZoneEscrowPartialServlet.testSFTPConnection(ZoneEscrowPartialServlet.java:562)
[classes:?]
at
cx.cocca.registry.maintenance.ZoneEscrowPartialServlet.doPost(ZoneEscrowPartialServlet.java:123)
[classes:?]
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:159) [javaee-16.jar:?]
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:97) [javaee-16.jar:?]
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:109)
[resin.jar:4.0.66]
at
Re: [I] Looking for release date for next release of mina-sshd [mina-sshd]
adelel1 commented on issue #487: URL: https://github.com/apache/mina-sshd/issues/487#issuecomment-2118045648 Hello, any update on this, either a patch release for 2.12 or a 2.13 release? -- 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
Re: [I] The arcfour256 algorithm fails to be configured with a specific mac algorithm [mina-sshd]
tomaswolf commented on issue #493: URL: https://github.com/apache/mina-sshd/issues/493#issuecomment-2116249742 Thank you for your investigations. This is fixed with commit 5a78e6d. -- 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
Re: [I] The arcfour256 algorithm fails to be configured with a specific mac algorithm [mina-sshd]
tomaswolf closed issue #493: The arcfour256 algorithm fails to be configured with a specific mac algorithm URL: https://github.com/apache/mina-sshd/issues/493 -- 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
Re: [I] SessionHelper#signalNegotiationEnd should pass reason through to listener [mina-sshd]
tomaswolf closed issue #504: SessionHelper#signalNegotiationEnd should pass reason through to listener URL: https://github.com/apache/mina-sshd/issues/504 -- 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
Re: [PR] issue-504 Pass reason to sessionNegotiationEnd [mina-sshd]
tomaswolf commented on PR #505: URL: https://github.com/apache/mina-sshd/pull/505#issuecomment-2116150530 Thank you! -- 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
Re: [PR] issue-504 Pass reason to sessionNegotiationEnd [mina-sshd]
tomaswolf merged PR #505: URL: https://github.com/apache/mina-sshd/pull/505 -- 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
Re: [I] The arcfour256 algorithm fails to be configured with a specific mac algorithm [mina-sshd]
tomaswolf commented on issue #493: URL: https://github.com/apache/mina-sshd/issues/493#issuecomment-2116149268 OK, thank you. Essentially: arcfour256 works only with the `hmac-*-etm` MACs. This is a bug; it's caused by wrong block sizes being set. Yes, arcfour128 and arcfour256 are stream ciphers, but a block size must be set anyway because SSH RFC 4253 insists that > Note that the length of the concatenation of 'packet_length', 'padding_length', 'payload', and 'random padding' MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced, even when using stream ciphers. [RFC 4253, section 6](https://datatracker.ietf.org/doc/html/rfc4253#page-7) So for arcfour128 and arcfour256, the "blocksize" must be 8. Unfortunately, this is wrong at https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java#L118 and at https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java#L129 The last parameter must not be 16 or 32 but 8. arcfour128 works by chance, arcfour256 will fail for small packets. I'll push a fix soon. -- 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
Re: [I] Perfomance file transfer [mina-sshd]
tomaswolf commented on issue #485: URL: https://github.com/apache/mina-sshd/issues/485#issuecomment-2115924971 So far I have not enough information to do anything. I have run my own speed tests, and I see no performance problem. Before I can do anything I need to be able to reproduce the problem that you observe. I would need detailed information about your setup: your client-side code, your test setup, what authentication mechanisms and ciphers are used, what's the size of the files, what Java version do you use, what hardware is your client running on, what server are you testing against and on what hardware or virtual machine or container is it running, what is the network latency, what buffer sizes are used, which of the I/O back-ends in Apache MINA SSHD are you using (NIO2, MINA, Netty?), and what is that "jsched" client that you keep mentioning? I have never heard of that. -- 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
[PR] issue-504 Pass reason to sessionNegotiationEnd [mina-sshd]
duco-lw opened a new pull request, #505: URL: https://github.com/apache/mina-sshd/pull/505 Addresses #504. -- 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
Re: [I] Perfomance file transfer [mina-sshd]
benz-ppi commented on issue #485: URL: https://github.com/apache/mina-sshd/issues/485#issuecomment-2115654272 Even with the changes you have suggested, transferring files with the SFTP Apache client software is significantly slower (> factor 3) than transferring files with jsched or winscp. Do you intend to improve the performance of the SFTP Apache client software? -- 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
Re: [I] SessionHelper#signalNegotiationEnd should pass reason through to listener [mina-sshd]
tomaswolf commented on issue #504: URL: https://github.com/apache/mina-sshd/issues/504#issuecomment-2115324310 Thanks for pointing this out. > Would ... break anything? No, it would not. Feel free 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
[I] SessionHelper#signalNegotiationEnd should pass reason through to listener [mina-sshd]
duco-lw opened a new issue, #504:
URL: https://github.com/apache/mina-sshd/issues/504
https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/SessionHelper.java#L1149
The `reason` is not passed through to the listener:
```
protected void signalNegotiationEnd(
SessionListener listener,
Map c2sOptions,
Map s2cOptions,
Map negotiatedGuess, Throwable
reason) {
if (listener == null) {
return;
}
listener.sessionNegotiationEnd(this, c2sOptions, s2cOptions,
negotiatedGuess, null);
}
```
The doc for this says the negotiation is successful if this is null:
```
/**
* Signals the end of the negotiation options handling
*
* @param session The referenced {@link Session}
* @param clientProposalThe client proposal options (un-modifiable)
* @param serverProposalThe server proposal options (un-modifiable)
* @param negotiatedOptions The successfully negotiated options so far -
even if exception occurred (un-modifiable)
* @param reasonNegotiation end reason - {@code null} if
successful
*/
default void sessionNegotiationEnd(
Session session,
Map clientProposal,
Map serverProposal,
Map negotiatedOptions,
Throwable reason) {
// ignored
}
```
https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-core/src/main/java/org/apache/sshd/common/session/SessionListener.java#L151
This looks like this will always be "successful", even in the error case?
```
} catch (IOException | RuntimeException | Error e) {
signalNegotiationEnd(c2sOptions, s2cOptions, negotiatedGuess, e);
throw e;
}
```
https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java#L2259
Would changing the line from
```
listener.sessionNegotiationEnd(this, c2sOptions, s2cOptions,
negotiatedGuess, null);
```
to
```
listener.sessionNegotiationEnd(this, c2sOptions, s2cOptions,
negotiatedGuess, reason);
```
break anything?
--
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
Re: [I] incorrect classloading of SecurityProviders [mina-sshd]
jtnord commented on issue #502: URL: https://github.com/apache/mina-sshd/issues/502#issuecomment-2112254784 (of note BouncyCastle also supports ED25519 curves as does JDK > 15) -- 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
[I] incorrect classloading of SecurityProviders [mina-sshd]
jtnord opened a new issue, #502: URL: https://github.com/apache/mina-sshd/issues/502 ### Version 2.12.1 ### Bug description The mina plugin attempts work out if EdDSA is supported using a different classloader than it actually uses for using `EdDSASecurityProviderUtils` leading to `ClassNotFoundExceptions` ### Actual behavior `NoClassDefError` ``` Caused by: java.lang.NoClassDefFoundError: net/i2p/crypto/eddsa/spec/EdDSAParameterSpec at org.apache.sshd.common.util.security.SecurityUtils.getEDDSAPublicKeyEntryDecoder(SecurityUtils.java:580) at org.apache.sshd.common.config.keys.KeyUtils.(KeyUtils.java:187) at org.apache.sshd.common.config.keys.loader.openssh.OpenSSHRSAPrivateKeyDecoder. ``` ### Expected behavior No classloading issues. the code uses the same classloader to load EdDSA as it uses to see if EdDSA is supported. ### Relevant log output ```Shell if you have a non flat classloader (e.g. Jenkins, or any modular app server) then the code has a non reflective way of determining if something is supported or not. e.g. https://github.com/apache/mina-sshd/blob/sshd-2.12.1/sshd-common/src/main/java/org/apache/sshd/common/util/security/SecurityUtils.java#L575-L581 we see a call to `isEDDSACurveSupported` before we attempt to use a staic method from the class `EdDSASecurityProviderUtils` However https://github.com/apache/mina-sshd/blob/sshd-2.12.1/sshd-common/src/main/java/org/apache/sshd/common/util/security/SecurityUtils.java#L566-L571 looks for the presence of a security provider called "EdDSA" which in no way reflects if the classes are available or not. If the "EdDSA" provider was statically registered in the bootclasspath this would work, however it is generally registered by [`EdDSASecurityProviderRegistrar`](https://github.com/apache/mina-sshd/blob/sshd-2.12.1/sshd-common/src/main/java/org/apache/sshd/common/util/security/eddsa/EdDSASecurityProviderRegistrar.java) As can be seen here https://github.com/apache/mina-sshd/blob/sshd-2.12.1/sshd-common/src/main/java/org/apache/sshd/common/util/security/eddsa/EdDSASecurityProviderRegistrar.java#L88-L101 this uses `ThreadUtils.resolveDefaultClass` to see if the class is available which adds a the Threads contextClassLoader into the mix to see if the class is there. If the class is available in the `contextClassloader` but not the current classload, then it would load as the Provider is created (eventually) [here](https://github.com/apache/mina-sshd/blob/sshd-2.12.1/sshd-common/src/main/java/org/apache/sshd/common/util/security/SecurityProviderChoice.java#L125-L128) which uses reflection and in the case of this issue the Threads contextClassLoader. The created provider is then registered in the JVM. This provider is then used as the gate for "are the EdDSA classes available" for the regular (current) classloader, which in this case they are not which causes a :boom: whilst it is generally safe to create and Provider dynamically like this, the code that uses the classes from the provider as opposed to the provider itself should take a different approach. Either they also need to be loaded by reflection (yikes), or the check to see if they are available should not use the provider, but should check the actual class is present in the **current** classloader (ie ignore the context classloader). Or providers should not be dynamically registered from a context classloader. ``` ### 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
Re: [I] I used the arcfour256 algorithm to connect to the sshserver of mina-sshd and encountered an exception [mina-sshd]
czldb2 commented on issue #493: URL: https://github.com/apache/mina-sshd/issues/493#issuecomment-2111928811 > No idea. I just tested arcfour128 and arcfour256 against an OpenSSH 7.4 server in CentOS 7.9 (2009), and an Apache MINA SSHD 2.13.0-SNAPSHOT client works just fine. Maybe try the latest release 2.12.1, or the 2.13.0-SNAPSHOT available from the Apache snapshot repositories. I found that when using arcfour256 algorithm, if the mac algorithm uses hmac-sha1-...@openssh.com, The hmac-sha2-256-...@openssh.com or hmac-sha2-512-...@openssh.com algorithm will work, but any other mac algorithm will fail. -- 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
Re: [I] heartbeat timeout of a session will cause the links of other sessions to be disconnected [mina-sshd]
tomaswolf commented on issue #461:
URL: https://github.com/apache/mina-sshd/issues/461#issuecomment-2106274419
Sorry for the long message, but when I looked at this it took me
surprisingly long to find my way through the code. I must say I find the
implementation of heartbeats _very_ confusing.
**TL;DR**: An immediate work-around for the reporter (@d9e7381f ) might be
to set `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` to zero. But we should
change the implementation, too.
**Long version**:
First, Apache MINA SSHD resets the session idle timeout whenever a message
is received or _is written_. So even sending a heartbeat with `wantReply ==
false` will reset the idle timeout.
So `wantReply == true` makes sense only if one wants to implement the
OpenSSH behaviour of `ClientAliveCountMax` or `ServerAliveCountMax`: terminate
the connection once that many heartbeats did _not_ get a reply (yet). But for
that one doesn't have to wait synchronously for the reply; we have
[asynchronous global
requests](https://github.com/apache/mina-sshd/blob/master/docs/technical/global_requests.md#api)
since version 2.9.0.
Second, _heartbeats are implemented twice_: once in
`AbstractConnectionService` and then again in `ClientConnectionService`, and
_there are two sets of configuration properties_. The server side gets the
behaviour of `AbstractConnectionService`.
`AbstractConnectionService` is configured with properties
`CommonModuleProperties.SESSION_HEARTBEAT_TYPE` (default "NONE", i.e., off) and
`CommonModuleProperties.SESSION_HEARTBEAT_INTERVAL` (default 0, i.e. disabled).
To enable, one needs to set an interval > 0, and type "IGNORE" or "RESERVED".
If the heartbeat type is "IGNORE", it'll send a fire-and-forget SSH_MSG_IGNORE.
If the heartbeat type is "RESERVED", it'll invoke a user handler that is
supposed to send the heartbeat, and it might choose to do so with a global or
channel request with `want-reply == true`.
Heartbeats in `ClientConnectionService` have additional configuration
properties `CoreModuleProperties.HEARTBEAT_INTERVAL` (default zero, i.e. off),
`CoreModuleProperties.HEARTBEAT_REQUEST` (default "keepal...@sshd.apache.org"),
and `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` (default **5 minutes**). To
enable this kind of heartbeat, set an interval > 0. It'll send a
SSH_MSG_GLOBAL_REQUEST for "keepal...@sshd.apache.org", and because
HEARTBEAT_REPLY_WAIT > 0, will send it with `wantReply == true` and _will wait
synchronously for five minutes_ for a reply to arrive. If no reply arrives in
time, kill the SSH session. (If HEARTBEAT_REQUEST_WAIT is <= 0, the request
will be sent with `wantReply == false`, i.e., fire-and-forget.) And to
complicate matters: if this "global request heartbeat" is off
(HEARTBEAT_INTERVAL <= 0), the above behavior from `AbstractConnectionService`
kicks in (which is by default disabled).
Plus there's an additional quirk: `AbstractConnectionService` does not send
heartbeats when a key exchange is ongoing. That was done for
[SSHD-1059](https://issues.apache.org/jira/browse/SSHD-1059), and since the
"strict KEX" extension ("Terrapin" mitigation) it's crucial because there must
not be any SSH_MSG_IGNORE messges during the initial key exchange. The
mechanism in `ClientConnectionService` has no such provision, but a
SSH_MSG_GLOBAL_REQUEST message will be delayed anyway until an ongoing key
exchange is over.
This is a mess. There should be only one set of properties governing
heartbeats.
The two separate mechanisms seem to have existed for a long time, and
changing that now would be an API break.
The 5 minutes default value comes from commit 14bbd54a5, which was about
[SSHD-1020](https://issues.apache.org/jira/browse/SSHD-1020). Reading that
discussion the issue seems to have been a low-level network I/O read timeout
(NIO2_READ_TIMEOUT) of ~10 min, and HEARTBEAT_REPLY_WAIT = 0. So even though
the client sent keep-alives every 90 sec, and the SSH idle timeout got reset,
the session got killed because nothing was received for 10min because the
server never sent any reply to these heartbeats because none was asked for. The
solution was to set NIO2_READ_TIMEOUT = 0 (no timeout for low-level I/O reads)
and that huge HEARTBEAT_REPLY_WAIT.
An immediate work-around for the reporter might be to set
`CoreModuleProperties.HEARTBEAT_REPLY_WAIT` to zero. That should work if there
is no low-level read timeout (NIO2_READ_TIMEOUT = 0).
But we should re-think this mechanism anyway. I propose to change this to
follow the path taken by OpenSSH:
* Ignore `CoreModuleProperties.HEARTBEAT_REPLY_WAIT` (and deprecate it now).
* Introduce a `CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX`: an integer, as
in OpenSSH's `ServerAliveCountMax`. I.e., maximum number of heartbeats to send
without having gotten a reply.
If
Re: [PR] DIRMINA-1173 [mina]
elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597523524
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
I missed the MSS part. Ok, so makes sense to keep the parameter as is, but I
do agree that *not* setting a default at all would be a better option. At
least, you let the developer makes a choice depending on what they actually
measure.
Thanks Jon!
--
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
Re: [PR] DIRMINA-1173 [mina]
jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597516034
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
See https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Nagle only really applies for when the packets are smaller than the MSS
which is usually 1280 bytes. AFAIK only the HELLO message in TLS HS is smaller
than this; all other messages SHOULD be aggregated together by the SSL layer.
There IS a _well known_ interaction with Nagle and Delayed Ack which can cause
Nagle to be worse than it would be by itself. What is the order of delays you
are seeing?
--
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
Re: [PR] DIRMINA-1173 [mina]
jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513918
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
In my other IO framework, all of the TCP/SOCK options all have `unset`
states where the framework code will not call the SOCK configuration at all and
allow the OS defaults to be applied.
--
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
Re: [PR] DIRMINA-1173 [mina]
elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513323
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Not arguing here, I will revert but...
I do think that this flag should be opt-in, ie the Nagle algorithm should be
disabled by default. The use cases were it's useful are not really the most
frequent, and the drawbacks are numerous. If the default sendBuffer size is
set to 64Ko, then you have a delayed for every packet that has a lower number
of bytes to transfert. if you set the sendBuffer size to a lower value, then
you are sending way more packet than needed. In any case, if you are to send
some data that span on more than one packet, and the last packet is not
completed, then you'll pay a 200ms delay every time. Not very cool.
With Gigabits connections, sending a lot of packets is not really an issue
anymore, except on heavily loaded applications that aren't interactive (HTTP
may enter into this category, but with REST application, I would argue that an
immediate sending is a plus).
Regarding LDAP, requests are small there is no interest in differing the
packet sendings, so yes, I'm likely to deactivate the Nagle Algorithm.
Seems like on Linux they have added the TCP_CORK parameter to let the sender
decide when to send the data, bypassing the Nagle's algorithm completely, and
also solving the context switching pb at the same time (somehow it's a way to
say "you're responsability, not teh OS one", and I tend to agree). Sadly, this
is not portable, so currently it's not an option.
Last, not least, for TLS HS, Nagle's Algorithm is delaying the whole
negociation, which is a real PITA...
--
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
Re: [I] Memory Leak When SftpFileSystemProvider newInputStream get a Exception [mina-sshd]
tomaswolf closed issue #500: Memory Leak When SftpFileSystemProvider newInputStream get a Exception URL: https://github.com/apache/mina-sshd/issues/500 -- 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
Re: [PR] GH-500: SftpFileSystemProvider: close SftpClient on exception [mina-sshd]
tomaswolf merged PR #501: URL: https://github.com/apache/mina-sshd/pull/501 -- 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
Re: [PR] DIRMINA-1173 [mina]
jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597475482
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Disabling Nagle by default may create context switching performance hits in
certain applications. Any situation where you may invoke more than one write
in sequence, receives performance boosts from the way the IO scheduler works in
TCP because it can produce MORE packets in a single go and does not have to be
woken up as often. The OS itself does not disable Nagle by default and I do
not think we should make this decision for the end user. As long as they can
configure it, I think the default should be `unset` (to allow the OS default to
apply). If other applications, built on MINA, want to configure a new default
then it is up to them. For SSHD or Apache Directory, if you want to disable
Nagle there, that is fine.
--
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
Re: [PR] DIRMINA-1173 [mina]
elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597473106
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hi @jon-valliere, just read this blog post:
https://brooker.co.za/blog/2024/05/09/nagle.html
Somehow, Nagle's algorithm is a thing of the past (ie when we were dealing
with terminals over slow connections). In MINA's context, and if we except
SSHD, I do think that the default to disable Nagle's algorithm actually makes
sense. Most of MINA based application don't deal with char by char
communication, rather with quite big chunks of data, so there is little need to
wait for an ACK from the server.
Anyway, this is configurable, so I guess it should not be a big deal.
--
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
[PR] GH-500: SftpFileSystemProvider: close SftpClient on exception [mina-sshd]
tomaswolf opened a new pull request, #501: URL: https://github.com/apache/mina-sshd/pull/501 If client.read() or client.write() throw an exception, the client must be closed. Fixes #500. -- 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
Re: [PR] DIRMINA-1173 [mina]
jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea. If we want todo this also,
I think it should be as part of a separate 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
Re: [PR] DIRMINA-1173 [mina]
jon-valliere commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597451055
##
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
-private static final boolean DEFAULT_TCP_NO_DELAY = false;
+private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Hey @elecharny I'm not sure this is a good idea
--
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
Re: [PR] Implement the "sntrup761x25519-sha...@openssh.com" KEX method [mina-sshd]
tomaswolf merged PR #498: URL: https://github.com/apache/mina-sshd/pull/498 -- 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
Re: [I] OsUtils#isAndroid() returns false on WearOS [mina-sshd]
tomaswolf commented on issue #499: URL: https://github.com/apache/mina-sshd/issues/499#issuecomment-2105658175 I think this was fixed in #476. Please try the 2.13.0-SNAPSHOT version available from the [Apache Snapshot](https://repository.apache.org/content/repositories/snapshots) maven repository. -- 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
[I] Memory Leak When SftpFileSystemProvider newInputStream get a Exception [mina-sshd]
detective0922 opened a new issue, #500:
URL: https://github.com/apache/mina-sshd/issues/500
### Version
V2.8.0
### Bug description
I checked the https://github.com/apache/mina-sshd/issues/294 and merge the
fix code to V2.8.0
That fixed the old issue, but there is still a issue here.
If a exception happen in FilterInputStream init, for example, a "No such
file" exception happen in init of FilterInputStream
`return new FilterInputStream(client.read(p.toString(), modes)) `
then it will not call the "client.close()", so SftpClient will not close and
keep increasing, finally lead to a OOM
2024-05-11 12:00:02,311 INFO [LoggerStream] - SFTP error
(SSH_FX_NO_SUCH_FILE): No such file
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.throwStatusException(AbstractSftpClient.java:217)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.checkAttributesResponse(AbstractSftpClient.java:306)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.checkAttributes(AbstractSftpClient.java:284)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.stat(AbstractSftpClient.java:1001)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.SftpInputStreamAsync.(SftpInputStreamAsync.java:69)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.impl.AbstractSftpClient.read(AbstractSftpClient.java:1189)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.fs.SftpFileSystem$Wrapper.read(SftpFileSystem.java:491)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.fs.SftpFileSystem$Wrapper.read(SftpFileSystem.java:483)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
org.apache.sshd.sftp.client.fs.SftpFileSystemProvider.newInputStream(SftpFileSystemProvider.java:525)
2024-05-11 12:00:02,311 INFO [LoggerStream] - at
java.nio.file.Files.newInputStream(Files.java:152)
```
@Override
public InputStream newInputStream(Path path, OpenOption... options)
throws IOException {
Collection modes =
OpenMode.fromOpenOptions(Arrays.asList(options));
if (modes.isEmpty()) {
modes = EnumSet.of(OpenMode.Read);
}
SftpPath p = toSftpPath(path);
//return p.getFileSystem().getClient().read(p.toString(), modes);
SftpClient client = p.getFileSystem().getClient();
return new FilterInputStream(client.read(p.toString(), modes)) {
//line 525
@Override
public void close() throws IOException {
try {
super.close();
} finally {
client.close();
}
}
};
}
```
### Actual behavior
Memory leak happen
### Expected behavior
No Memory Leak
### 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
[I] OsUtils#isAndroid() returns false on WearOS [mina-sshd]
Brad1944 opened a new issue, #499:
URL: https://github.com/apache/mina-sshd/issues/499
### Version
2.12.1
### Bug description
I noticed that ExceptionUtils#peelException() returns a somewhat weird
exception on my GW6 (java.lang.NoClassDefFoundError: Failed resolution of:
Ljavax/management/ReflectionException), after digging into its code I found
that this code got triggered when its not supposed to
```java
// Android does not have these classes
if (!OsUtils.isAndroid()) {
if (t instanceof ReflectionException) {
Throwable target = ((ReflectionException) t).getTargetException();
if (target != null) {
return peelException(target);
}
} else if (t instanceof MBeanException) {
Throwable target = ((MBeanException) t).getTargetException();
if (target != null) {
return peelException(target);
}
}
}
```
After inspecting it by debug logs, I found out that OsUtils#isAndroid()
returns false when its supposed to be true
### Actual behavior
It returns false
### Expected behavior
It returns true?
### Relevant log output
```Shell
FATAL EXCEPTION: main
Process: top.apip.sftpserver, PID: 27567
java.lang.NoClassDefFoundError: Failed resolution of:
Ljavax/management/ReflectionException;
at
org.apache.sshd.common.util.ExceptionUtils.peelException(ExceptionUtils.java:126)
at
org.apache.sshd.common.util.ExceptionUtils.peelException(ExceptionUtils.java:118)
at
org.apache.sshd.common.util.security.SecurityEntityFactory$1.getInstance(SecurityEntityFactory.java:93)
at
org.apache.sshd.common.util.security.SecurityUtils.getKeyAgreement(SecurityUtils.java:772)
at
org.apache.sshd.common.kex.MontgomeryCurve.(MontgomeryCurve.java:121)
at
org.apache.sshd.common.kex.MontgomeryCurve.(MontgomeryCurve.java:95)
at
org.apache.sshd.common.kex.BuiltinDHFactories$13.isSupported(BuiltinDHFactories.java:260)
at
org.apache.sshd.common.NamedFactory.lambda$setUpTransformedFactories$0(NamedFactory.java:54)
at
org.apache.sshd.common.NamedFactory$$ExternalSyntheticLambda0.test(D8$$SyntheticClass:0)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:184)
at
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:475)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:236)
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:517)
at
org.apache.sshd.common.NamedFactory.setUpTransformedFactories(NamedFactory.java:56)
at
org.apache.sshd.server.ServerBuilder.setUpDefaultKeyExchanges(ServerBuilder.java:178)
at
org.apache.sshd.server.ServerBuilder.fillWithDefaultValues(ServerBuilder.java:119)
at
org.apache.sshd.server.ServerBuilder.fillWithDefaultValues(ServerBuilder.java:58)
at org.apache.sshd.common.BaseBuilder.build(BaseBuilder.java:273)
at org.apache.sshd.server.ServerBuilder.build(ServerBuilder.java:151)
at org.apache.sshd.server.ServerBuilder.build(ServerBuilder.java:58)
at org.apache.sshd.common.BaseBuilder.build(BaseBuilder.java:297)
at
org.apache.sshd.server.SshServer.setUpDefaultServer(SshServer.java:442)
at
top.apip.sftpserver.presentation.MainActivityKt.SetupSftpServer(MainActivity.kt:135)
at
top.apip.sftpserver.presentation.ComposableSingletons$MainActivityKt$lambda-1$1.invoke(MainActivity.kt:67)
at
top.apip.sftpserver.presentation.ComposableSingletons$MainActivityKt$lambda-1$1.invoke(MainActivity.kt:66)
at
androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:108)
at
androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:35)
at
androidx.compose.ui.platform.ComposeView.Content(ComposeView.android.kt:428)
at
androidx.compose.ui.platform.AbstractComposeView$ensureCompositionCreated$1.invoke(ComposeView.android.kt:252)
at
androidx.compose.ui.platform.AbstractComposeView$ensureCompositionCreated$1.invoke(ComposeView.android.kt:251)
at
androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:108)
at
androidx.compose.runtime.internal.ComposableLambdaImpl.invoke(ComposableLambda.jvm.kt:35)
at
androidx.compose.runtime.CompositionLocalKt.CompositionLocalProvider(CompositionLocal.kt:228)
at
androidx.compose.ui.platform.CompositionLocalsKt.ProvideCommonCompositionLocals(CompositionLocals.kt:195)
at
Re: [I] Support for Java 9+ modules [mina-sshd]
rich7409 commented on issue #497: URL: https://github.com/apache/mina-sshd/issues/497#issuecomment-2104406846 Thanks for the tip. Excluding core and common and using osgi instead has stopped it complaining about the modules. I'll look forward to future versions with full module support. We're a lot of releases since Java 9 first came out but it's still a struggle with the modules because quite a few third party libraries don't have them included. I'm still not sure my code is working properly when they are enforced. -- 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
Re: [I] Support for Java 9+ modules [mina-sshd]
rich7409 closed issue #497: Support for Java 9+ modules URL: https://github.com/apache/mina-sshd/issues/497 -- 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
Re: [I] Support for Java 9+ modules [mina-sshd]
tomaswolf commented on issue #497: URL: https://github.com/apache/mina-sshd/issues/497#issuecomment-2104142524 I agree this is a mess. That split into core and common was done in an awkward way that introduced split packages. Those are problematic not only with the Java module system but also in OSGi. There is the `org.apache.sshd.osgi` artifact; it avoids this split package problem by re-combining core and common into one. For OSGi that works; it might also work for Java modules. However, if you use not OSGi with package imports only but a plain "fat jar" platform, you should probably override dependencies of other bundles (for instance, of "sftp") by excluding the "core" and "common" dependencies and adding the "osgi" dependency instead. -- 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
[PR] Implement the "sntrup761x25519-sha...@openssh.com" KEX method [mina-sshd]
tomaswolf opened a new pull request, #498: URL: https://github.com/apache/mina-sshd/pull/498 This uses a post-quantum key encapsulation method (KEM) to make key exchange future-proof against quantum attacks. It is to be preferred over curve25519-sha256 "when the extra communication size and computational requirements are acceptable."[1] (curve25519-sha256 exchanged 32 bytes where sntrup761x25519-sha512 exchanges 1190 or 1071 bytes.) This KEX method changes the encoding of the key from 'mpint' to 'string'. To make the handling of the K value more uniform, change it to 'string' everywhere, and convert mpints with the high bit set explicitly by prepending a zero byte. Separate the digest from MontgomeryCurve; handle combining curves and hashes (and KEMs) in the BuiltinDHFactories instead. In the BaseBuilder, add "sntrup761x25519-sha...@openssh.com" as first (i.e., preferred) KEX algorithm. [1] https://www.ietf.org/archive/id/draft-josefsson-ntruprime-ssh-02.html -- 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
[I] Support for Java 9+ modules [mina-sshd]
rich7409 opened a new issue, #497: URL: https://github.com/apache/mina-sshd/issues/497 ### Description Hello. I'm trying to switch over from JSch to Mina SSHD but it's playing havoc with the Java 9 module system. There are packages in both sshd-core and sshd-common, and the modules system won't play ball with that. For example: error: module spring.integration.sftp reads package org.apache.sshd.common.auth from both org.apache.sshd.core and org.apache.sshd.common Do you have plans to make a Java 9 or greater release of SSHD that has full module-info.java in each part of the system? Thanks, Richard. ### Motivation To be able to use Mina SSHD with Java9+ module path without errors. ### Alternatives considered Forking and moving the classes myself, then building with module-info.java in the source and building for Java 11. ### 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
Re: [I] Enable ssh-dss algorighthm through system variable [mina-sshd]
abhikt48 commented on issue #483: URL: https://github.com/apache/mina-sshd/issues/483#issuecomment-2101048025 Can anyone please update on this ? -- 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
