Re: Issue with private keys
Hi, On 27.01.22 21:44 , José Danilo Ross Lépiz wrote: Currently I'm working on migrating an application using JGit to use SSHD but I have not been able to get private key login working. Could I be missing any configuration? This is the stacktrace I get: Caused by: java.lang.NoClassDefFoundError: java/security/spec/PKCS8EncodedKeySpec at org.bouncycastle.jcajce.provider.asymmetric.rsa.KeyFactorySpi.engineGeneratePrivate(Unknown Source) ~[bcprov-jdk15on-1.70.jar:1.70.0] at java.security.KeyFactory.generatePrivate(KeyFactory.java:384) ~[?:?] at org.apache.sshd.common.config.keys.impl.AbstractKeyEntryResolver.generatePrivateKey(AbstractKeyEntryResolver.java:52) ~[sshd-osgi-2.7.0.jar:2.7.0] at org.apache.sshd.common.config.keys.loader.openssh.OpenSSHRSAPrivateKeyDecoder.decodePrivateKey(OpenSSHRSAPrivateKeyDecoder.java:83) ~[sshd-osgi-2.7.0.jar:2.7.0] [...] No idea. This is really surprising. What Java version is this running on? Usually such things are classpath problems. But missing a core class? You're not alone, though; see [1]. Unfortunately there's no answer there, either. [1] https://stackoverflow.com/questions/67376583/noclassdeffounderror-pkcs8encodedkeyspec-when-running-in-tomcat - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Re: Restarting ssh server inside single jvm
On 16.08.23 11:51 , Slawomir Skalka wrote:
Given:
jdk 19.0.2.7 (Temurin)
sshd-core 2.10.0
sshd-common 2.10.0
slf4j-api 1.7.36
And: Windows.
attached code causes circa 50 exceptions:
Exception in thread "Thread-3" Exception in thread "Thread-2"
java.lang.IllegalStateException: Executor has been shut down
at
org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
at
org.apache.sshd.common.util.ValidateUtils.throwIllegalStateException(ValidateUtils.java:207)
at
org.apache.sshd.common.util.ValidateUtils.checkState(ValidateUtils.java:184)
at
org.apache.sshd.common.util.threads.NoCloseExecutor.execute(NoCloseExecutor.java:100)
at
java.base/sun.nio.ch.AsynchronousChannelGroupImpl.executeOnPooledThread(AsynchronousChannelGroupImpl.java:190)
at java.base/sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:215)
at java.base/sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:316)
at
java.base/sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl$AcceptTask.failed(WindowsAsynchronousServerSocketChannelImpl.java:288)
at java.base/sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:389)
at java.base/java.lang.Thread.run(Thread.java:1589)
Code causing exception:
public static void main(String[] args) throws Exception {
for (int i = 0; i < 100; i++) {
var sshd = SshServer.setUpDefaultServer();
var hostKeyProvider = new SimpleGeneratorHostKeyProvider(
Paths.get(".", "cert"));
hostKeyProvider.setAlgorithm(KeyUtils.RSA_ALGORITHM);
sshd.setKeyPairProvider(hostKeyProvider);
sshd.start();
sshd.stop(false);
}
}
This is just a code to easily reproduce the exception. In our product
we start and stop the server at a far way lower rate, but still we
observe the exception being thrown.
I wonder if there should be any additional method called after/before
server stop or if this is some kind of a bug, or is the server restart
somehow forbidden or unadvised?
No, this should work.
Or maybe it is this specific jvm fault
This problem appears to be specific to Windows. I cannot reproduce on OS
X, but I can easily reproduce on Windows.
This is actually an implementation difference in
AsynchronousServerSocketChannel between Unix and Windows.
The channel (used by the acceptor) is closed asynchronously, and there
is a java.nio.channels.AsynchronousCloseException to be reported.
The Unix implementation in
sun.nio.ch.UnixAsynchronousServerSocketChannelImpl calls the acceptor's
completion handler in Nio2Acceptor.AcceptCompletionHandler.onFailed()
directly.
The Windows implementation in
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl calls it
indirectly via the thread pool executor of the AsynchronousChannelGroup,
but that executor is already shut down.
Not sure if this is a JDK bug in the Windows implementation, or what we
could do about it. It looks like the underlying
OverlappedChannel.close() in the Windows implementation in the JDK is
asynchronous, and that there is a race with the shutdown of the executor.
Cheers,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org
Re: Help understand SSHD server exception "bad length"
On 07.10.22 17:31 , Stefan Müller wrote: The SSHD server shows following error while receiving an file: [NioProcessor-18] [WARN ] exceptionCaught(ServerSessionImpl[])[state=Opened] IllegalStateException: Bad length (32796) for cmd=SSH_MSG_CHANNEL_DATA - max. allowed=32768 My first thought is that it is only a warning and I can ignore it. But the received file is empty. After looking at the source code i think it is an error and the client sends too much data. Can somebody explain what is going on? I know this is nearly a year old, but maybe you're still interested. We've finally figured it out. It appears to be a bug in a particular SFTP client. See * https://github.com/apache/mina-sshd/issues/403 * https://community.progress.com/s/question/0D54QASQm9FSQT/bad-length-32796-for-cmdsshmsgchanneldata-max-allowed32768 Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Re: Restarting ssh server inside single jvm
On 24.08.23 00:41 , Thomas Wolf wrote: On 16.08.23 11:51 , Slawomir Skalka wrote: Given: jdk 19.0.2.7 (Temurin) sshd-core 2.10.0 sshd-common 2.10.0 slf4j-api 1.7.36 And: Windows. attached code causes circa 50 exceptions: [...] This problem appears to be specific to Windows. I cannot reproduce on OS X, but I can easily reproduce on Windows. [...] I've opened an issue for this: https://github.com/apache/mina-sshd/issues/409 . Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Time for a release of Apache MINA sshd 2.9.0?
Hi, how about cutting a 2.9.0 release of Apache MINA sshd? 2.8.0 was in December 2021. I think we've got enough to warrant a new release: * Major refactoring of KEX * Major refactoring of TCP/IP port forwarding * Major refactoring of global requests * New feature: OpenSSH host-based publickey authentication * New feature: Argon2id-encrypted PuTTY keys * New feature: lim...@openssh.com SFTP extension * A number of bug fixes Thoughts? Is someone still working on something and would like to have it included in 2.9.0? Open Jira issues that we should resolve before 2.9.0? Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Re: Time for a release of Apache MINA sshd 2.9.0?
On 07.06.22 19:17 , Lyor Goldstein wrote: >> how about cutting a 2.9.0 release of Apache MINA sshd? 2.8.0 was in December 2021. I think we've got enough to warrant a new release +1 - totally agree One week later: since a major change in 2.9.0 would be the refactored TCP/IP port forwarding, I'd also like to get PR 227[1] for SSHD-1055[2] in, and then a fix for SSHD-1269[3] that I've already prepared. Then we'd really be good to go in my opinion. Cheers, Thomas [1] https://github.com/apache/mina-sshd/pull/227 [2] https://issues.apache.org/jira/browse/SSHD-1055 [3] https://issues.apache.org/jira/browse/SSHD-1269 - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Re: Time for a release of Apache MINA sshd 2.9.0?
From my side everything is in. Guillaume, could you please prepare a 2.9.0 release? Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Apache MINA: how to half-close an NioSocketSession?
Hi, in Apache MINA sshd I recently[1] ran into the problem of how to shut down output on a socket using MINA 2.0.23. Apache MINA sshd had some code that used reflection to get at the SocketChannel of an NioSocketSession, and then invoked channel.shutdownOutput() on that directly. That kind of worked, but it led to very strange effects where all SSH tests, when run with MINA, took very long. (Unfortunately I don't know for sure why because I never could reproduce this locally and the Apache MINA sshd CI builds on Github don't provide any useful logs after the build has terminated.) I did notice in some local tests that quite frequently the AbstractPollingIoProcessor.Processor entered its "epoll spinning" code; so maybe that was the reason. In any case: what's the proper way to half-close an NioSocketSession? With NIO2, it's no problem. Netty also has a proper DuplexChannel abstraction via which we can do this. But with MINA, the only working way for Apache MINA sshd is to call IoSession.closeOnFlush(). That works for our use case, but it isn't quite the same as a half-closure via shutdownOutput(). On a related note: what is the proper way in Apache MINA to handle IoHandler.inputClosed()? As I understand it, that indicates that whatever is on the other end closed its output. But we may still write, right? IoHandlerAdapter just closes the session immediately, though. I tried to use IoSession.suspendRead(), but that again leads to epoll spinning. Just not closing session (i.e., an empty implementation of inputClosed()) leads to ClosedByInterruptExceptions when the session finally is closed. Any hints? Cheers, Thomas [1] https://github.com/apache/mina-sshd/pull/227 - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Re: Help understand SSHD server exception "bad length"
On 07.10.22 17:31 , Stefan Müller wrote: The SSHD server shows following error while receiving an file: [NioProcessor-18] [WARN ] exceptionCaught(ServerSessionImpl[])[state=Opened] IllegalStateException: Bad length (32796) for cmd=SSH_MSG_CHANNEL_DATA - max. allowed=32768 My first thought is that it is only a warning and I can ignore it. But the received file is empty. After looking at the source code i think it is an error and the client sends too much data. Can somebody explain what is going on? Not fully from this description, but I agree that the message indicates that a client sent a packet larger than the maximum packet size the server allows on the channel. What maximum packet size does the client have for this channel (should be in the SSH_MSG_CHANNEL_OPEN message; if you switch on debug logging, you should be able to see it). What client is this? Also Apache MINA sshd, or something else? If not Apache MINA sshd, there's nothing we can do, and the problem needs to be fixed in the buggy client. And what operation is performed exactly? You mention "file upload"... via SFTP or SCP? Cheers, Thomas - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
[ANNOUNCE] Apache MINA SSHD release 2.9.2
The Apache MINA project is pleased to announce the release of Apache MINA SSHD 2.9.2. This is a bug fix release, see https://github.com/apache/mina-sshd/blob/master/docs/changes/2.9.2.md for the details. The release is available for download at https://mina.apache.org/sshd-project/downloads.html and is also available via Maven Central. Thanks for all the contributions and the feedback that made this release possible! For the Apache MINA project, Thomas Wolf - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
Fwd: CVE-2022-45047: Apache MINA SSHD: Java unsafe deserialization vulnerability
The new Apache MINA SSHD 2.9.2 release also fixes CVE-2022-45047. Forwarded Message Subject: CVE-2022-45047: Apache MINA SSHD: Java unsafe deserialization vulnerability Date: Tue, 15 Nov 2022 23:08:17 + From: Thomas Wolf Reply-To: d...@mina.apache.org To: annou...@apache.org, d...@mina.apache.org Severity: important Description: Class org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider in Apache MINA SSHD <= 2.9.1 uses Java deserialization to load a serialized java.security.PrivateKey. The class is one of several implementations that an implementor using Apache MINA SSHD can choose for loading the host keys of an SSH server. Mitigation: For Apache MINA SSHD <= 2.9.1, do not use org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider to generate and later load your server's host key. Use separately generated host key files, for instance in OpenSSH format, and load them via a org.apache.sshd.common.keyprovider.FileKeyPairProvider instead. Or use a custom implementation instead of SimpleGeneratorHostKeyProvider that uses the OpenSSH format for storing and loading the host key (via classes OpenSSHKeyPairResourceWriter and OpenSSHKeyPairResourceParser). The issue was fixed in Apache MINA SSHD 2.9.2. Credit: The Apache MINA SSHD team would like to thank Zhang Zewei, NOFOCUS, for reporting this issue. - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org - To unsubscribe, e-mail: users-unsubscr...@mina.apache.org For additional commands, e-mail: users-h...@mina.apache.org
