[jira] [Comment Edited] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766857#comment-17766857
]
Lyor Goldstein edited comment on SSHD-1333 at 9/19/23 3:45 PM:
---
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense. Please
note that we can only support what SCP protocol allows - adding a bunch of
options that have no meaning only muddle the API. If you need to call
{{FileSystemProvider#copy(Path, Path, CopyOption...)}} then do so after
translating the SCP options to {{CopyOption}}-s - if such translation is even
possible
{code:java|title=StandardCopyOption(s)}
package java.nio.file;
/**
* Defines the standard copy options.
*
* @since 1.7
*/
public enum StandardCopyOption implements CopyOption {
/**
* Replace an existing file if it exists.
*/
REPLACE_EXISTING,
/**
* Copy attributes to the new file.
*/
COPY_ATTRIBUTES,
/**
* Move the file as an atomic file system operation.
*/
ATOMIC_MOVE;
}
{code}
{code:java|title=SCP options}
public interface ScpClient extends SessionHolder,
ClientSessionHolder {
enum Option {
Recursive("-r"),
PreserveAttributes("-p"),
TargetIsDirectory("-d"),
;
private final String optionValue;
Option(String optionValue) {
this.optionValue = optionValue;
}
/**
* @return The option value to use in the issued SCP command
*/
public String getOptionValue() {
return optionValue;
}
}
{code}
was (Author: lgoldstein):
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense.
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> Thanks in advance?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766857#comment-17766857
]
Lyor Goldstein commented on SSHD-1333:
--
I understand that - my question was what would be the +semantics+ of the extra
supported options. Please note that any other option makes no sense.
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> Thanks in advance?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-1335) Add landing directory feature
Ananth kumar created SSHD-1335:
--
Summary: Add landing directory feature
Key: SSHD-1335
URL: https://issues.apache.org/jira/browse/SSHD-1335
Project: MINA SSHD
Issue Type: Improvement
Reporter: Ananth kumar
Currently, we are able to set only the home directory using the
VirtualFileSystemFactory class.
Our requirement is to land the user in the subdirectories of the home directory.
Is some feature can be provided to land the user in a different directory?
Eg:
The User A has the home directory as /A. But the User A should be landed into
the /A/B directory after login
Current scenario:
{code:java}
sftp> pwd
/{code}
required Scenario:
{code:java}
sftp> pwd
/B {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766698#comment-17766698
]
dgü commented on SSHD-1333:
---
If this feature is added, overrided copy method will be fully compatible with
{_}FileSystemProvider#copy(Path, Path, CopyOption...){_}.
Thanks!
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> Thanks in advance?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1330:
-
Affects Version/s: 2.10.0
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work started] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1330 started by Lyor Goldstein.
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766453#comment-17766453
]
Lyor Goldstein commented on SSHD-1330:
--
This is the 1st time we encounter servers sending {{keepalive}} global requests
to clients. However, I see no reason why not to implement your suggestion.
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1330) keep-alive handler on client
[
https://issues.apache.org/jira/browse/SSHD-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1330:
Assignee: Lyor Goldstein
> keep-alive handler on client
>
>
> Key: SSHD-1330
> URL: https://issues.apache.org/jira/browse/SSHD-1330
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Florian Hof
>Assignee: Lyor Goldstein
>Priority: Minor
>
> After a connection using the default SFTP client, I get lot's of WARN logs
> like the following:
> {{handleUnknownRequest(ClientConnectionService[ClientSessionImpl[x...@sftp-intern.xxx.com/xx.xx.xx.xx:993]])
> unknown global request: keepal...@proftpd.org}}
> It seems that the server send keep-alive messages to the client. The
> {{[KeepAliveHandler|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/server/global/KeepAliveHandler.java]}}
> handles this properly. It is per default in the server handlers. I propose
> to add it per default in the client handlers. This shouldn't have negative
> effect, should it? Adding it afterwards avoids the WARN logs.
> Implementation on
> {{[ClientBuilder.DEFAULT_GLOBAL_REQUEST_HANDLERS|https://github.com/apache/mina-sshd/blob/master/sshd-core/src/main/java/org/apache/sshd/client/ClientBuilder.java#L69-L70]}}
> would be trivial:
> {code:java}
> public static final List>
> DEFAULT_GLOBAL_REQUEST_HANDLERS
> = List.of(OpenSshHostKeysHandler.INSTANCE,
> KeepAliveHandler.INSTANCE);
> {code}
> (and eventually move the {{KeepAliveHandler}} from
> {{org.apache.sshd.*server*.global}} to
> {{{}org.apache.sshd.*common*.global{}}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1333) Adding java.nio.file.CopyOption to SCP transfer methods
[
https://issues.apache.org/jira/browse/SSHD-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766451#comment-17766451
]
Lyor Goldstein commented on SSHD-1333:
--
I don't see the use-case for this - what extra options would make sense ?
> Adding java.nio.file.CopyOption to SCP transfer methods
> ---
>
> Key: SSHD-1333
> URL: https://issues.apache.org/jira/browse/SSHD-1333
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: dgü
>Priority: Major
>
> Hello!
> remote-to-remote file transfer is available in SCP protocol. If I'm not
> wrong, it is not available in SFTP protocol.
> I'm trying to use the following code to handle remote-to-remote file transfer.
> {code:java}
> public class SSHDFileSystemProvider extends SftpFileSystemProvider {
> private final static String URI_SCHEME = "ssh";
>
> private final static boolean PRESERVE_ATTRIBUTES = true;
> @Override
> public String getScheme() {
> return URI_SCHEME;
> }
> @Override
> public void copy(Path sourcePath, Path targetPath, CopyOption... options)
> throws IOException {
> ClientSession sourceClientSession = ((SftpFileSystem)
> (sourcePath.getFileSystem())).getClientSession();
> ClientSession targetClientSession = ((SftpFileSystem)
> (targetPath.getFileSystem())).getClientSession();
> ScpRemote2RemoteTransferHelper helper = new
> ScpRemote2RemoteTransferHelper(sourceClientSession, targetClientSession);
> helper.transferFile(sourcePath.toString(), targetPath.toString(),
> PRESERVE_ATTRIBUTES);
> }
> }
> {code}
> _ScpRemote2RemoteTransferHelper.transferFile(String,String,boolean)_ accepts
> preserve attributes only as the copy option.
> My request:
> - is it possible to add java.nio.file.CopyOption to SCP transfer methods?
> Thanks in advance?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764105#comment-17764105
]
Alexander B commented on DIRMINA-1172:
--
Thanks a lot. (y)
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRMINA-1172.
Fix Version/s: 2.2.3
2.0.25
2.1.8
Resolution: Fixed
Fixed by adding the local address port in the Datagram session key
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-996) IoSessionRecycler RemoteAddress Collision
[
https://issues.apache.org/jira/browse/DIRMINA-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRMINA-996.
---
Fix Version/s: 2.2.3
2.0.25
2.1.8
Resolution: Fixed
I fixed the issue by creating a key that also contains the local port:
{code:java}
String key = session.getRemoteAddress() + ":" +
((InetSocketAddress)session.getLocalAddress()).getPort(); {code}
> IoSessionRecycler RemoteAddress Collision
> -
>
> Key: DIRMINA-996
> URL: https://issues.apache.org/jira/browse/DIRMINA-996
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.7
>Reporter: Flavio Battimo
>Assignee: Jonathan Valliere
>Priority: Critical
> Fix For: 2.2.3, 2.0.25, 2.1.8
>
>
> When using NioDatagramAcceptor with multiple binded local addresses the
> IoSessionRecycler is not working as expected.
> If the acceptor has been prefilled with two sessions:
> remoteaddr=192.168.1.10:2001 localaddr=192.168.1.20:1000
> remoteaddr=192.168.1.10:2001 localaddr=192.168.1.20:1001
> so with same remote address but different local address, when the recycle
> method of IoSessionRecycler interface is called only remote address is
> passed. The recycler returns the same IoSession for incoming datagrams on two
> different local addresses of the same acceptor.
> The IoSessionRecycler should have the local address parameter also in order
> to find the correct IoSession.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759366#comment-17759366
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi Alexander,
will work on a triple release (2.0,X, 2.1.X and 2.2.X in the coming days). Not
a lot of available time, but that should not take me a lot of time either.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758563#comment-17758563
]
Alexander B commented on DIRMINA-1172:
--
Actually, the two Cmd's are running in parallel.
But, anyway, I think, if it works now - would it be possible to fix this
officially in 2.1.x and/or 2.2.x ?
Thanks a lot
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758540#comment-17758540
]
Emmanuel Lécharny commented on DIRMINA-1172:
The session does not last forever, may be it expired in scenario 2?
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758460#comment-17758460
]
Alexander B commented on DIRMINA-1172:
--
Actually, I still did not get the clue. Before, the port was not part of the
session key. And scenario 2 worked before. It was just scenario 3, that did not
work. Scenario 2 and 3 are both sending to different ports. The difference is
just from two applications or just from one. In both scenarios you can find
just one sending machine.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758452#comment-17758452
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi, Alexender,
they do have the same IP address, but they aren't sending the data to the same
port. Now that the port is part of the session key, two sessions will be
created.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758431#comment-17758431
]
Alexander B commented on DIRMINA-1172:
--
Thanks a lot - i think my three scenarios are working fine now.
What I actually don't understand is the second scenario: There are two Cmds
from one machine sending to a target machine. For me it seems that these
senders should have the same remote address - don't they? Why did this work
before as well? Just the case sending to two different ports from one
application (on one machine) to one target machine seems to be problematic?
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758062#comment-17758062
]
Alexander B commented on DIRMINA-1172:
--
Yes, this should be enough. In our dependency-list I can just see
`org.apache.mina.mina-core`.
I will replace this and let you know.
Thanks so far.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRMINA-1172:
---
Attachment: mina-core-2.2.3-SNAPSHOT.jar
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758030#comment-17758030
]
Emmanuel Lécharny commented on DIRMINA-1172:
Tell me which jar you requires. If it's only mina-core, find it attachaed.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz, mina-core-2.2.3-SNAPSHOT.jar
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758025#comment-17758025
]
Alexander B commented on DIRMINA-1172:
--
Thanks a lot for a fast fix.
I will try it. Give me a bit of time - I try to combine your jar files with
our maven project.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRMINA-1172:
---
Attachment: apache-mina-2.2.3-SNAPSHOT-bin.tar.gz
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.3-SNAPSHOT-bin.tar.gz
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRMINA-1172:
---
Attachment: (was: apache-mina-2.2.2-bin.tar.gz)
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757997#comment-17757997
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi Alexander,
could you give the attached package a try, please?
Thanks!
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRMINA-1172:
---
Attachment: apache-mina-2.2.2-bin.tar.gz
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java,
> apache-mina-2.2.2-bin.tar.gz
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757914#comment-17757914
]
Emmanuel Lécharny commented on DIRMINA-1172:
The idea is to build a key that contains the remote address and the local port.
All in all, there is no reason to create a session that is shared between two
ports.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757888#comment-17757888
]
Alexander B commented on DIRMINA-1172:
--
But would it be correct, that you handle TCP-Sessions (NioSocketConnector's) on
another way (including the remote port or anything like this)?
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757818#comment-17757818
]
Emmanuel Lécharny commented on DIRMINA-1172:
Ok, if I create two instances, I get to see that there is only one acceptor
receiving all the messages, whatever the port used.
The problem is that we keep sessions in a cache with the key being the
RemoteAdress, the port not being taken into account:
{code:java}
private ExpiringMap sessionMap;
public void put(IoSession session) {
mapExpirer.startExpiringIfNotStarted();
SocketAddress key = session.getRemoteAddress();
if (!sessionMap.containsKey(key)) {
sessionMap.put(key, session);
}
} {code}
At this point, we must certainly need to inject the port in the key, which will
require some modification in the session map handling.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757437#comment-17757437
]
Alexander B edited comment on DIRMINA-1172 at 8/22/23 12:57 PM:
Sorry, I was not able to take a closer look or to prepare something (at the
moment), but as I can see, you are using 1 object and bind two ports at the
same object.
Compared to our code, I am pretty sure, that we are using two different
instances, therefore two different NioDatagramAcceptors and two different
handlers.
was (Author: abuechel):
Sorry, I was not able to take a closer look or to prepare something, but as I
can see, you are using 1 object and bind two ports at the same object.
Compared to our code, I am pretty sure, that we use two different instances,
therefore two different NioDatagramAcceptors and two different Handlers.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757437#comment-17757437
]
Alexander B commented on DIRMINA-1172:
--
Sorry, I was not able to take a closer look or to prepare something, but as I
can see, you are using 1 object and bind two ports at the same object.
Compared to our code, I am pretty sure, that we use two different instances,
therefore two different NioDatagramAcceptors and two different Handlers.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRMINA-1172:
---
Attachment: DIRMINA1172.java
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: DIRMINA1172.java, UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757411#comment-17757411
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi Alexander,
I think I have a working test (see attachement). It's a bit brutal.
What I see is that for both port, the session is the same. Investigating.
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17757242#comment-17757242
]
Emmanuel Lécharny commented on DIRMINA-1172:
Hi Alexander,
may I ask you to provide a fully functionnal test? It will spare me the time to
recreate something I can test. Thanks!
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1172) Multiple DatagramAcceptors and the creation of a session object
[
https://issues.apache.org/jira/browse/DIRMINA-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756334#comment-17756334
]
Alexander B commented on DIRMINA-1172:
--
Hi [~elecharny] ,
i know i am nerving a little bit. But I would like to ask again, if you already
find something about the behaviour above?
Thank a lot
Alex
> Multiple DatagramAcceptors and the creation of a session object
> ---
>
> Key: DIRMINA-1172
> URL: https://issues.apache.org/jira/browse/DIRMINA-1172
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.5
>Reporter: Alexander B
>Priority: Major
> Attachments: UDPTest4.java
>
>
> Hello,
> I am using two independently created NioDatagramAcceptors, which are created
> by the following code :
> {code:java}
> AbstractIoService inputSource = new NioDatagramAcceptor();
> ((NioDatagramAcceptor) inputSource).getSessionConfig().setReuseAddress(true);
> DefaultIoFilterChainBuilder filterChainBuilderUDP =
> ((NioDatagramAcceptor)inputSource).getFilterChain();
> filterChainBuilderUDP.addLast("logger", new LoggingFilter());
> ((NioDatagramAcceptor)
> inputSource).getSessionConfig().setIdleTime(IdleStatus.READER_IDLE,
> getIdleTimeout());
> ((NioDatagramAcceptor) inputSource).setHandler(this);
> try {
> ((NioDatagramAcceptor)inputSource).bind(new InetSocketAddress(port));
> } catch (IOException e) {
> log.error("Failed to connect {}", e);
> }
> {code}
> One Acceptor is listening on port 9800, the other one on 9801. If I now send
> UDP packages (from a external application) to both ports (independently). It
> seems, that both UDP port are "connected" to the same session.
> Information: The external app is sending:
> Message "TEST_1 " just to port 9800
> Message "TEST_2 " just to port 9801
> The overwritten method messageReceived will give the following output:
> {code:java}
> public void messageReceived(IoSession session, Object message) throws
> Exception {
> String msgStr = message.toString();
> log.info("SessionId:" + session.getId() + " " + msgStr);
> }
> {code}
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-2] INFO - SessionId:1 TEST_1
> 1681904855701
> 2023-04-19_11:47:35.035 [NioDatagramAcceptor-3] INFO - SessionId:1 TEST_2
> 1681904855701
> So, both messages (for port 9800 and port 9801) are received by SessionId1.
> If I do exactly the same with `NioSocketConnector`, I can see two different
> sessions, such that both messages are handled independently:
> 2023-04-19_11:44:35.725 [NioProcessor-11] INFO - SessionId:1 TEST_1
> 1681904875701
> 2023-04-19_11:44:37.754 [NioProcessor-15] INFO - SessionId:2 TEST_2
> 1681904875701
> Is there anything I did not mention in the context of UDP/DatagramAcceptor?
> Or is there any setting, such that DatagramAcceptors can create/handle their
> own session objects?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1331) SSH Algorithm negotiation
[
https://issues.apache.org/jira/browse/SSHD-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pohner resolved SSHD-1331.
Resolution: Information Provided
Thanks a lot, [~twolf], I suppose that makes more sense. I'll try reordering
the signature algorithms then.
> SSH Algorithm negotiation
> --
>
> Key: SSHD-1331
> URL: https://issues.apache.org/jira/browse/SSHD-1331
> Project: MINA SSHD
> Issue Type: Question
>Affects Versions: 2.9.2
>Reporter: Pavel Pohner
>Priority: Major
>
> Hello,
> I'm facing a weird issue with SSH signature algorithm negotiation:
> Signature algorithms for RSA are sorted like this in my implementation:
>
> {code:java}
> List RSA_SIGNATURES = List.of(
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsaSHA512_cert,
> BuiltinSignatures.rsaSHA256_cert,
> BuiltinSignatures.rsaSHA512,
> BuiltinSignatures.rsaSHA256 {code}
> when establishing connection with server that offers following lists of
> algorithms, the connection is established without any issue:
> {code:java}
> ssh-rsa
> rsa-sha2-512
> rsa-sha2-256 {code}
> but, when server with list of algorithms in following order is encountered:
> {code:java}
> rsa-sha2-512
> rsa-sha2-256
> ssh-rsa {code}
> the connection fails with following exception: *KeyExchange signature
> verification failed for key type=ssh-rsa*
> Based on SSH RFC my current understanding is, that in the second scenario,
> algorithm guessing happens, where my implementation (client), guesses the
> *ssh-rsa* algorithm, meanwhile the server guesses the {*}rsa-sha2-512{*}, in
> that case the guess is not successful and there's defined algorithm that must
> be followed (basically, client iterating over the common list of algorithms
> until finding the correct match) -
> [https://datatracker.ietf.org/doc/html/rfc4253#section-7.1]
> This seems to not be the case though as the exception says that the signature
> verification failed for *ssh-rsa,* I would expect the implementation to
> iterate to the *rsa-sha2-512* and match the server's guessed algorithm.
> How is this handled in Mina SSHD implementation? Is this something I can
> override/handle in my own implementation? Can someone point me in the right
> direction please?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (DIRMINA-1175) Question about the Correctness of the Affected Scope of Vulnerability CVE-2023-35887 on NVD
[ https://issues.apache.org/jira/browse/DIRMINA-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRMINA-1175. Resolution: Information Provided > Question about the Correctness of the Affected Scope of Vulnerability > CVE-2023-35887 on NVD > --- > > Key: DIRMINA-1175 > URL: https://issues.apache.org/jira/browse/DIRMINA-1175 > Project: MINA > Issue Type: Wish >Reporter: Radar wen >Priority: Minor > > We see from NVD that vulnerability CVE-2023-35887 affects Apache MINA > ([https://nvd.nist.gov/vuln/detail/CVE-2023-35887)] > However, we looked for a lot of information, including the reference links, > the Apache MINA community, but we didn't see any discussion of whether it > affected Apache MINA, only that this issue affected Apache MINA SSHD. > https://lists.apache.org/thread/b9qgtqvhnvgfpn0w1gz918p21p53tqk2 > https://www.cve.org/CVERecord?id=CVE-2023-35887 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35887 > https://vuldb.com/?id.233305 > https://issues.apache.org/jira/browse/SSHD-1324 > Then we consulted the reporter of original source of the issue: > (https://github.com/apache/mina-sshd/pull/362), and the answer was: The issue > affects the Apache Mina SSHD project, not the Apache Mina library. > > > So, we would like to consult, is the NVD affected scope inaccurate? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1175) Question about the Correctness of the Affected Scope of Vulnerability CVE-2023-35887 on NVD
[ https://issues.apache.org/jira/browse/DIRMINA-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17751918#comment-17751918 ] Emmanuel Lécharny commented on DIRMINA-1175: Hi, the issue is being addressed. We don"t discuss vulnerability on public mailing lists, that is the reason you can't find a status there. > Question about the Correctness of the Affected Scope of Vulnerability > CVE-2023-35887 on NVD > --- > > Key: DIRMINA-1175 > URL: https://issues.apache.org/jira/browse/DIRMINA-1175 > Project: MINA > Issue Type: Wish >Reporter: Radar wen >Priority: Minor > > We see from NVD that vulnerability CVE-2023-35887 affects Apache MINA > ([https://nvd.nist.gov/vuln/detail/CVE-2023-35887)] > However, we looked for a lot of information, including the reference links, > the Apache MINA community, but we didn't see any discussion of whether it > affected Apache MINA, only that this issue affected Apache MINA SSHD. > https://lists.apache.org/thread/b9qgtqvhnvgfpn0w1gz918p21p53tqk2 > https://www.cve.org/CVERecord?id=CVE-2023-35887 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35887 > https://vuldb.com/?id.233305 > https://issues.apache.org/jira/browse/SSHD-1324 > Then we consulted the reporter of original source of the issue: > (https://github.com/apache/mina-sshd/pull/362), and the answer was: The issue > affects the Apache Mina SSHD project, not the Apache Mina library. > > > So, we would like to consult, is the NVD affected scope inaccurate? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (DIRMINA-1175) Question about the Correctness of the Affected Scope of Vulnerability CVE-2023-35887 on NVD
Radar wen created DIRMINA-1175: -- Summary: Question about the Correctness of the Affected Scope of Vulnerability CVE-2023-35887 on NVD Key: DIRMINA-1175 URL: https://issues.apache.org/jira/browse/DIRMINA-1175 Project: MINA Issue Type: Wish Reporter: Radar wen We see from NVD that vulnerability CVE-2023-35887 affects Apache MINA ([https://nvd.nist.gov/vuln/detail/CVE-2023-35887)] However, we looked for a lot of information, including the reference links, the Apache MINA community, but we didn't see any discussion of whether it affected Apache MINA, only that this issue affected Apache MINA SSHD. https://lists.apache.org/thread/b9qgtqvhnvgfpn0w1gz918p21p53tqk2 https://www.cve.org/CVERecord?id=CVE-2023-35887 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-35887 https://vuldb.com/?id.233305 https://issues.apache.org/jira/browse/SSHD-1324 Then we consulted the reporter of original source of the issue: (https://github.com/apache/mina-sshd/pull/362), and the answer was: The issue affects the Apache Mina SSHD project, not the Apache Mina library. So, we would like to consult, is the NVD affected scope inaccurate? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the exit status result, and
there is a dedicated property to adjust this timeout. Though, this is not
really a solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DE
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the exit status result, and
there is a dedicated property to adjust this timeout. Though, this is not
really a solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like {_}runUpload(){_}, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DE
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DE
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the ```handleCommandExitStatus(cmd,
channel)``` is called before the In/Out channels are auto-closed by the
try-with-resources block, and thus the EOF is not sent to the remote prior to
handling the exit status. The current implementation always times out first and
then sends an EOF while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
was:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the `handleCommandExitStatus(cmd, channel)`
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the ```handleCommandExitStatus(cmd,
> channel)``` is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> `DefaultScpClient::runUpload()` which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
was:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the ```handleCommandExitStatus(cmd,
channel)``` is called before the In/Out channels are auto-closed by the
try-with-resources block, and thus the EOF is not sent to the remote prior to
handling the exit status. The current implementation always times out first and
then sends an EOF while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the _handleCommandExitStatus(cmd,
> channel)_ is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> _DefaultScpClient::runUpload()_ which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async
[jira] [Created] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
Ryan Livingston created SSHD-1334:
-
Summary: DefaultScpClient::upload(InputStream, ...) will always
hit the exit status timeout
Key: SSHD-1334
URL: https://issues.apache.org/jira/browse/SSHD-1334
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.10.0
Reporter: Ryan Livingston
Attachments: file-based.txt, stream-based.txt
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the `handleCommandExitStatus(cmd, channel)`
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Attachment: file-based.txt
stream-based.txt
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the `handleCommandExitStatus(cmd,
> channel)` is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> `DefaultScpClient::runUpload()` which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async issues when
> processing some remaining inbound messages from the remote after the pipe is
> closed.
> This issue is persistent on remote SSH servers running with CentOS and MacOS.
> This example is being run on MacOS 13.3.1 with a remote SSH server that has
> no explicit SSH configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke closed SSHD-1329.
---
Resolution: Not A Bug
Closing as this breaking change seems to be intentional behaviour.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionI
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750651#comment-17750651
]
Tobias Gierke commented on SSHD-1329:
-
To answer my own question: One can simply do
{code:java}
sshClient.setHostConfigEntryResolver( (host, port, localAddress, username,
proxyJump, context) -> null ); {code}
to completely disable the ~/.ssh/config file.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750632#comment-17750632
]
Tobias Gierke commented on SSHD-1329:
-
I feel tempted to close this ticket as it seems the breakage observed by me
(introduced by
[https://github.com/apache/mina-sshd/commit/c11bfccaa39d5c89c3f3059f976dd1e4d0947cb6])
was done deliberately so nothing will be changed about it (which is fine with
me).
Is there a way to configure the client so that it completely ignores any local
~/.ssh/config file ? If yes, how to do so ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey
[jira] [Commented] (FTPSERVER-521) Failure connecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version
[ https://issues.apache.org/jira/browse/FTPSERVER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743698#comment-17743698 ] Roberto Deandrea commented on FTPSERVER-521: Can you please comment about this issue ? > Failure connecting to Apache FTP/S server from curl command negotiating TLS > 1.3 protocol version > > > Key: FTPSERVER-521 > URL: https://issues.apache.org/jira/browse/FTPSERVER-521 > Project: FtpServer > Issue Type: Bug > Components: Server >Affects Versions: 1.1.4 > Environment: Operating System: Linux x64 > uname -a > Linux ITTO-62117757H 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > curl client used: > curl -V > curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 > brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) > libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14 > Release-Date: 2022-01-05 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps > mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 > Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd > JRE used : > usr/lib/jvm/jdk8u372-b07-jre/bin/java -version > openjdk version "1.8.0_372" > OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-b07) > OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b07, mixed mode) >Reporter: Roberto Deandrea >Priority: Major > Attachments: EmbeddingFtpServer.java, curl.log, ftpserver.log > > > I do not succeed connecting curl to Apache FTPS/S server negotiating TLS11.3 > protocol version (curl forcing TLS 1.2 works fine without any problems). > I reproduced the problem with minor changed to EmbeddingFtpServer.java source > attached to the jira. > In the attached file curl.log you can find the curl client log. > From curl.log it seems that the TLS 1.3 hanshake ended succesfully, but the > client does not receive a reply to the subsequent USER command, times out and > closes the connection. > * TLSv1.3 (OUT), TLS handshake, Finished (20) > SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > > USER spazio > * TLSv1.2 (IN), TLS header, Supplemental data (23): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * server response timeout > * Closing connection 0 > > Do you think this is a problem in the Apache FTPS Server code or inside the > JSSE layer of the JRE ? > > Thank you in advance for your cooperation. > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (FTPSERVER-446) Implementing User Manager not possible in OSGi environment
[
https://issues.apache.org/jira/browse/FTPSERVER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742308#comment-17742308
]
Emmanuel Lécharny commented on FTPSERVER-446:
-
Reviving FtpServer project, I have applied the \{{UserMetadata}} patch. More to
come!
> Implementing User Manager not possible in OSGi environment
> --
>
> Key: FTPSERVER-446
> URL: https://issues.apache.org/jira/browse/FTPSERVER-446
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Reporter: Dave Roberts
>Priority: Major
> Attachments: concurrentlogin.patch, transferrate.patch,
> writerequest.patch
>
>
> The USER class checks to see if the user logging in is permitted to do so
> concurrently. This is done by creating an instance of
> org.apache.ftpserver.usermanager.impl.ConcurrentLoginRequest and passing that
> to the authorize(AuthorizationRequest) method for the User object.
> Unless the User implementation is the one supplied by FTP Server, then the
> request cannot be handled because the org.apache.ftpserver.usermanager.impl
> package is not exported by the OSGi bundle.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (FTPSERVER-521) Failure connecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version
[ https://issues.apache.org/jira/browse/FTPSERVER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roberto Deandrea updated FTPSERVER-521: --- Attachment: ftpserver.log > Failure connecting to Apache FTP/S server from curl command negotiating TLS > 1.3 protocol version > > > Key: FTPSERVER-521 > URL: https://issues.apache.org/jira/browse/FTPSERVER-521 > Project: FtpServer > Issue Type: Bug > Components: Server >Affects Versions: 1.1.4 > Environment: Operating System: Linux x64 > uname -a > Linux ITTO-62117757H 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > curl client used: > curl -V > curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 > brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) > libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14 > Release-Date: 2022-01-05 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps > mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 > Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd > JRE used : > usr/lib/jvm/jdk8u372-b07-jre/bin/java -version > openjdk version "1.8.0_372" > OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-b07) > OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b07, mixed mode) >Reporter: Roberto Deandrea >Priority: Major > Attachments: EmbeddingFtpServer.java, curl.log, ftpserver.log > > > I do not succeed connecting curl to Apache FTPS/S server negotiating TLS11.3 > protocol version (curl forcing TLS 1.2 works fine without any problems). > I reproduced the problem with minor changed to EmbeddingFtpServer.java source > attached to the jira. > In the attached file curl.log you can find the curl client log. > From curl.log it seems that the TLS 1.3 hanshake ended succesfully, but the > client does not receive a reply to the subsequent USER command, times out and > closes the connection. > * TLSv1.3 (OUT), TLS handshake, Finished (20) > SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > > USER spazio > * TLSv1.2 (IN), TLS header, Supplemental data (23): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * server response timeout > * Closing connection 0 > > Do you think this is a problem in the Apache FTPS Server code or inside the > JSSE layer of the JRE ? > > Thank you in advance for your cooperation. > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (FTPSERVER-521) Failure connecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version
[ https://issues.apache.org/jira/browse/FTPSERVER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roberto Deandrea updated FTPSERVER-521: --- Summary: Failure connecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version (was: Failureconnecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version) > Failure connecting to Apache FTP/S server from curl command negotiating TLS > 1.3 protocol version > > > Key: FTPSERVER-521 > URL: https://issues.apache.org/jira/browse/FTPSERVER-521 > Project: FtpServer > Issue Type: Bug > Components: Server >Affects Versions: 1.1.4 > Environment: Operating System: Linux x64 > uname -a > Linux ITTO-62117757H 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > curl client used: > curl -V > curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 > brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) > libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14 > Release-Date: 2022-01-05 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps > mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 > Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd > JRE used : > usr/lib/jvm/jdk8u372-b07-jre/bin/java -version > openjdk version "1.8.0_372" > OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-b07) > OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b07, mixed mode) >Reporter: Roberto Deandrea >Priority: Major > Attachments: EmbeddingFtpServer.java, curl.log > > > I do not succeed connecting curl to Apache FTPS/S server negotiating TLS11.3 > protocol version (curl forcing TLS 1.2 works fine without any problems). > I reproduced the problem with minor changed to EmbeddingFtpServer.java source > attached to the jira. > In the attached file curl.log you can find the curl client log. > From curl.log it seems that the TLS 1.3 hanshake ended succesfully, but the > client does not receive a reply to the subsequent USER command, times out and > closes the connection. > * TLSv1.3 (OUT), TLS handshake, Finished (20) > SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > > USER spazio > * TLSv1.2 (IN), TLS header, Supplemental data (23): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * server response timeout > * Closing connection 0 > > Do you think this is a problem in the Apache FTPS Server code or inside the > JSSE layer of the JRE ? > > Thank you in advance for your cooperation. > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (FTPSERVER-521) Failureconnecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version
[ https://issues.apache.org/jira/browse/FTPSERVER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roberto Deandrea updated FTPSERVER-521: --- Summary: Failureconnecting to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version (was: Failed to connect to Apache FTP/S server from curl command negotiating TLS 1.3 protocol version) > Failureconnecting to Apache FTP/S server from curl command negotiating TLS > 1.3 protocol version > --- > > Key: FTPSERVER-521 > URL: https://issues.apache.org/jira/browse/FTPSERVER-521 > Project: FtpServer > Issue Type: Bug > Components: Server >Affects Versions: 1.1.4 > Environment: Operating System: Linux x64 > uname -a > Linux ITTO-62117757H 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC > Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux > curl client used: > curl -V > curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 > brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) > libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14 > Release-Date: 2022-01-05 > Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps > mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp > Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 > Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd > JRE used : > usr/lib/jvm/jdk8u372-b07-jre/bin/java -version > openjdk version "1.8.0_372" > OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-b07) > OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b07, mixed mode) >Reporter: Roberto Deandrea >Priority: Major > Attachments: EmbeddingFtpServer.java, curl.log > > > I do not succeed connecting curl to Apache FTPS/S server negotiating TLS11.3 > protocol version (curl forcing TLS 1.2 works fine without any problems). > I reproduced the problem with minor changed to EmbeddingFtpServer.java source > attached to the jira. > In the attached file curl.log you can find the curl client log. > From curl.log it seems that the TLS 1.3 hanshake ended succesfully, but the > client does not receive a reply to the subsequent USER command, times out and > closes the connection. > * TLSv1.3 (OUT), TLS handshake, Finished (20) > SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > > USER spazio > * TLSv1.2 (IN), TLS header, Supplemental data (23): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * server response timeout > * Closing connection 0 > > Do you think this is a problem in the Apache FTPS Server code or inside the > JSSE layer of the JRE ? > > Thank you in advance for your cooperation. > Roberto Deandrea > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741592#comment-17741592
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 1:17 PM:
--
Ok, having now read through [https://github.com/apache/mina-sshd/issues/281]
and [https://github.com/apache/mina-sshd/pull/353] I probably need to re-phrase
my last comment:
As I guess there is no "correct" way to skin this cat as processing order of
~/.ssh/config entries does not seem to be very well defined in any case - how
do I initialiize my SSH client in 2.10.0 so that it completely (or as much as
possible) *ignores* ~/.ssh/config , basically pretending the file does not
exist ? I do not want my programmatically configured SSH client to be dependent
on configuration that is specific to the host it is running on.
was (Author: tgierke2342):
Ok, having now read through [https://github.com/apache/mina-sshd/issues/281]
and [https://github.com/apache/mina-sshd/pull/353] I probably need to re-phrase
my last comment:
As I guess there is no "correct" way to skin this cat as processing order of
~/.ssh/config entries does not seem to be very well defined in any case - how
do I initialiize my SSH client in 2.10.0 so that it completely (or as much as
possible) *ignores* ~/.ssh/config , basically pretending the file does not
exist ? I do not want my programatically configured SSH client to be dependent
on configuration that is specific to the host it is running on.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741592#comment-17741592
]
Tobias Gierke commented on SSHD-1329:
-
Ok, having now read through [https://github.com/apache/mina-sshd/issues/281]
and [https://github.com/apache/mina-sshd/pull/353] I probably need to re-phrase
my last comment:
As I guess there is no "correct" way to skin this cat as processing order of
~/.ssh/config entries does not seem to be very well defined in any case - how
do I initialiize my SSH client in 2.10.0 so that it completely (or as much as
possible) *ignores* ~/.ssh/config , basically pretending the file does not
exist ? I do not want my programatically configured SSH client to be dependent
on configuration that is specific to the host it is running on.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.sessi
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741587#comment-17741587
]
Tobias Gierke commented on SSHD-1329:
-
This all lead me to
[https://github.com/apache/mina-sshd/commit/c11bfccaa39d5c89c3f3059f976dd1e4d0947cb6]
which seems to have introduced this difference in behavior.
Whether it was a concious decision to keep the old (IMHO buggy) behavior of
2.9.2 and change 2.10.0 only I do not know but the "Host *" setting not being
applied looks like a bug in 2.9.2 to me.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKe
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741585#comment-17741585
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 12:15 PM:
---
Putting a field breakpoint on the HostConfigEntry#exclusiveIdentities field
shows that in 2.10.0, the field value on the specific host entry
("vmtobi.fritzbox.local") is getting assigned from the wildcard ("*") host
configuration which I think is correct.
!image-2023-07-10-13-55-03-270.png!
On 2.9.2 there is no HostConfigEntry#collate() method at all.
was (Author: tgierke2342):
Putting a field breakpoint on the HostConfigEntry#exclusiveIdentities field
shows that in 2.10.0, the field value on the specific host entry
("vmtobi.fritzbox.local") is getting assigned from the wildcard ("*") host
configuration which I think is correct.
!image-2023-07-10-13-55-03-270.png!
On 2.9.2 there is no HostConfigEntry#collate() method at all.
This lead me to
[https://github.com/apache/mina-sshd/commit/c11bfccaa39d5c89c3f3059f976dd1e4d0947cb6]
which seems to have introduced this difference in behavior.
Whether it was a concious decision to keep the old (IMHO buggy) behavior of
2.9.2 and change 2.10.0 only I do not know but the "Host *" setting not being
applied looks like a bug in 2.9.2 to me.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=fals
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741585#comment-17741585
]
Tobias Gierke commented on SSHD-1329:
-
Putting a field breakpoint on the HostConfigEntry#exclusiveIdentities field
shows that in 2.10.0, the field value on the specific host entry
("vmtobi.fritzbox.local") is getting assigned from the wildcard ("*") host
configuration which I think is correct.
!image-2023-07-10-13-55-03-270.png!
On 2.9.2 there is no HostConfigEntry#collate() method at all.
This lead me to
[https://github.com/apache/mina-sshd/commit/c11bfccaa39d5c89c3f3059f976dd1e4d0947cb6]
which seems to have introduced this difference in behavior.
Whether it was a concious decision to keep the old (IMHO buggy) behavior of
2.9.2 and change 2.10.0 only I do not know but the "Host *" setting not being
applied looks like a bug in 2.9.2 to me.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,53
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-55-03-270.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.1
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741572#comment-17741572
]
Tobias Gierke commented on SSHD-1329:
-
Ok, I've narrowed the issue down to this ~/.ssh/config:
{code:java}
Host *
ForwardAgent yes
IdentitiesOnly yes{code}
On 2.9.2 , the unit test in my example project completes sucessfully while on
2.10.0 the unit test fails.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshC
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741571#comment-17741571
]
Tobias Gierke commented on SSHD-1329:
-
Seems my test case is incomplete without my ~/.ssh/config file which is rather
large (organic growth over a couple of years) and contains confidential
settings from work so I unfortunately cannot simply attach it to this ticket.
This also explains why the test fails on my Ubuntu 22.04.2 LTS but not on yours.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.18
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741567#comment-17741567
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 11:20 AM:
---
HostConfigEntry#isIdentitiesOnly():
+2.9.2+
!image-2023-07-10-13-16-35-068.png!
+2.10.0+
!image-2023-07-10-13-19-06-606.png!
So... on 2.10.0 , the
org.apache.sshd.client.config.hosts.HostConfigEntry#exclusiveIdentites field is
set to "true" while on 2.9.2 it is set to "false".
was (Author: tgierke2342):
HostConfigEntry#isIdentitiesOnly():
+2.9.2+
!image-2023-07-10-13-16-35-068.png!
+2.10.0+
!image-2023-07-10-13-19-06-606.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClie
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741567#comment-17741567
]
Tobias Gierke commented on SSHD-1329:
-
HostConfigEntry#isIdentitiesOnly():
+2.9.2+
!image-2023-07-10-13-16-35-068.png!
+2.10.0+
!image-2023-07-10-13-19-06-606.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-19-06-606.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-16-35-068.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,53
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-12-39-566.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[49
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741560#comment-17741560
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 11:11 AM:
---
The SshClient#onConnectOperationComplete methods are different in 2.10.0 and
2.9.2
What's more interesting is the fact that on 2.9.2 the "useDefaultEntities" is
set to "true" while on 2.10.0 it is set to "false".
+2.10.0+
!image-2023-07-10-13-08-54-869.png!
+2.9.2+
!image-2023-07-10-13-06-17-767.png!
So now the question is: Why does "hostConfig.isIdentitiesOnly()" yield
different values on 2.9.2 and 2.10.0 ?
was (Author: tgierke2342):
The SshClient#onConnectOperationComplete methods are different in 2.10.0 and
2.9.2
What's more interesting is the fact that on 2.9.2 the "useDefaultEntities" is
set to "true" while on 2.10.0 it is set to "false".
+2.10.0+
!image-2023-07-10-13-08-54-869.png!
+2.9.2+
!image-2023-07-10-13-06-17-767.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshCl
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741560#comment-17741560
]
Tobias Gierke commented on SSHD-1329:
-
The SshClient#onConnectOperationComplete methods are different in 2.10.0 and
2.9.2
What's more interesting is the fact that on 2.9.2 the "useDefaultEntities" is
set to "true" while on 2.10.0 it is set to "false".
+2.10.0+
!image-2023-07-10-13-08-54-869.png!
+2.9.2+
!image-2023-07-10-13-06-17-767.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshCli
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-08-54-869.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-13-06-17-767.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey []
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741551#comment-17741551
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 11:04 AM:
---
+2.9.2+
The org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider
field is never assigned so stays at its initial value which is NULL.
+2.10.0+
The field value is set to the "EMPTY" provider by
org.apache.sshd.client.SshClient#onConnectOperationComplete
!image-2023-07-10-12-53-51-624.png! which gets called by
!image-2023-07-10-13-04-05-241.png!
was (Author: tgierke2342):
+2.9.2+
The org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider
field is never assigned so stays at its initial value which is NULL.
+2.10.0+
The field value is set to the "EMPTY" provider by
org.apache.sshd.client.SshClient#onConnectOperationComplete
!image-2023-07-10-12-53-51-624.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741551#comment-17741551
]
Tobias Gierke commented on SSHD-1329:
-
+2.9.2+
The org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider
field is never assigned so stays at its initial value which is NULL.
+2.10.0+
The field value is set to the "EMPTY" provider by
org.apache.sshd.client.SshClient#onConnectOperationComplete
!image-2023-07-10-12-53-51-624.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSession
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-53-51-624.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionI
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741548#comment-17741548
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:48 AM:
---
This now raises the question: Why is the
org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider field
on 2.9.2 NULL (which is being handled correctly by
resolveEffectiveKeyProvider() while it is set to the "EMPTY" provider on 2.10.0
(which is *not* being handled correctly by resolveEffectiveKeyProvider) ?
was (Author: tgierke2342):
This now raises the question: Why is the
org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider field
on 2.9.2 NULL (which is being handled correctly by
resolveEffectiveKeyProvider() while it is set to the "EMPTY" provider on 2.10.
(which is *not* being handled correctly by resolveEffectiveKeyProvider) ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] D
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741548#comment-17741548
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:47 AM:
---
This now raises the question: Why is the
org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider field
on 2.9.2 NULL (which is being handled correctly by
resolveEffectiveKeyProvider() while it is set to the "EMPTY" provider on 2.10.
(which is *not* being handled correctly by resolveEffectiveKeyProvider) ?
was (Author: tgierke2342):
This now raises the question: Why does is the
org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider field
on 2.9.2 NULL (which is being handled correctly by
resolveEffectiveKeyProvider() while it is set to the "EMPTY" provider on 2.10.
(which is *not* being handled correctly by resolveEffectiveKeyProvider) ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741548#comment-17741548
]
Tobias Gierke commented on SSHD-1329:
-
This now raises the question: Why does is the
org.apache.sshd.client.session.AbstractClientSession#keyIdentityProvider field
on 2.9.2 NULL (which is being handled correctly by
resolveEffectiveKeyProvider() while it is set to the "EMPTY" provider on 2.10.
(which is *not* being handled correctly by resolveEffectiveKeyProvider) ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.f
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741544#comment-17741544
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:45 AM:
---
This question leads to
org.apache.sshd.client.session.AbstractClientSession#getKeyIdentityProvider
+2.10.0+
getKeyIdentityProvider() is being called with "keyIdentityProvider" being the
"EMPTY" provider
!image-2023-07-10-12-39-26-768.png!
and since resolveEffectiveProvider is just a checking for NULL but not the
"EMPTY" provider, it returns the "EMPTY" provider.
!image-2023-07-10-12-40-44-093.png!
+2.9.2+
When getKeyIdentityProvider() is being called, the "keyIdentityProvider" field
is set to NULL (not the "EMPTY" provider as in 2.10.0) so
resolveEffectiveProvider() returns the "inherited" argument which happens to be
the org.apache.sshd.common.keyprovider.FileKeyPairProvider that's gone missing
in 2.10.0
!image-2023-07-10-12-43-11-445.png!
was (Author: tgierke2342):
This question leads to
org.apache.sshd.client.session.AbstractClientSession#getKeyIdentityProvider
2.10.0
getKeyIdentityProvider() is being called with "keyIdentityProvider" being the
"EMPTY" provider
!image-2023-07-10-12-39-26-768.png!
and since resolveEffectiveProvider is just a checking for NULL but not the
"EMPTY" provider, it returns the "EMPTY" provider.
!image-2023-07-10-12-40-44-093.png!
2.9.2
When getKeyIdentityProvider() is being called, the "keyIdentityProvider" field
is set to NULL (not the "EMPTY" provider as in 2.10.0) so
resolveEffectiveProvider() returns the "inherited" argument which happens to be
the org.apache.sshd.common.keyprovider.FileKeyPairProvider that's gone missing
in 2.10.0
!image-2023-07-10-12-43-11-445.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
> ----
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-threa
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741544#comment-17741544
]
Tobias Gierke commented on SSHD-1329:
-
This question leads to
org.apache.sshd.client.session.AbstractClientSession#getKeyIdentityProvider
2.10.0
getKeyIdentityProvider() is being called with "keyIdentityProvider" being the
"EMPTY" provider
!image-2023-07-10-12-39-26-768.png!
and since resolveEffectiveProvider is just a checking for NULL but not the
"EMPTY" provider, it returns the "EMPTY" provider.
!image-2023-07-10-12-40-44-093.png!
2.9.2
When getKeyIdentityProvider() is being called, the "keyIdentityProvider" field
is set to NULL (not the "EMPTY" provider as in 2.10.0) so
resolveEffectiveProvider() returns the "inherited" argument which happens to be
the org.apache.sshd.common.keyprovider.FileKeyPairProvider that's gone missing
in 2.10.0
!image-2023-07-10-12-43-11-445.png!
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-43-11-445.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> Use
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-40-44-093.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-39-26-768.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-38-23-160.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741536#comment-17741536
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:34 AM:
---
2.9.2
Call stack of *first* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider is this:
!image-2023-07-10-12-25-51-220.png!
Call stack of *second* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-24-22-392.png!
2.10.0
Call stack of only KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-28-40-339.png!
So while on 2.9.2 the second resolveIdentityProvider() call (triggered by the
messageReceived() method) does have a non-empty KeyIdentityProvider, 2.10.0
only calls resolveIdentityProvider() once (also from messageReceived()) but in
this case the KeyIdentityProvider is still empty.
So the question is: Why does
org.apache.sshd.client.session.ClientSession#getKeyIdentityProvider return an
empty provider on 2.10.0 but not on 2.9.2 ?
was (Author: tgierke2342):
2.9.2
Call stack of *first* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider is this:
!image-2023-07-10-12-25-51-220.png!
Call stack of *second* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-24-22-392.png!
2.10.0
Call stack of only KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-28-40-339.png!
So while on 2.9.2 the second resolveIdentityProvider() call (triggered by the
messageReceived() method) does have a non-empty KeyIdentityProvider, 2.10.0
only calls resolveIdentityProvider() once (also from messageReceived()) but in
this case the KeyIdentityProvider is still empty.
So the question is now: Why does
org.apache.sshd.client.session.ClientSession#getKeyIdentityProvider return an
empty provider on 2.10.0 but not on 2.9.2 ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fri
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741536#comment-17741536
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:33 AM:
---
2.9.2
Call stack of *first* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider is this:
!image-2023-07-10-12-25-51-220.png!
Call stack of *second* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-24-22-392.png!
2.10.0
Call stack of only KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-28-40-339.png!
So while on 2.9.2 the second resolveIdentityProvider() call (triggered by the
messageReceived() method) does have a non-empty KeyIdentityProvider, 2.10.0
only calls resolveIdentityProvider() once (also from messageReceived()) but in
this case the KeyIdentityProvider is still empty.
So the question is now: Why does
org.apache.sshd.client.session.ClientSession#getKeyIdentityProvider return an
empty provider on 2.10.0 but not on 2.9.2 ?
was (Author: tgierke2342):
2.9.2
Call stack of *first* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider is this:
!image-2023-07-10-12-25-51-220.png!
Call stack of *second* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-24-22-392.png!
2.10.0
Call stack of only KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-28-40-339.png!
So while on 2.9.2 the second resolveIdentityProvider() call (triggered by the
messageReceived() method) does have a non-empty KeyIdentityProvider, 2.10.0
only calls resolveIdentityProvider() once (also from messageReceived()) but in
this case the KeyIdentityProvider is still empty.
So the questionnow is: Why does
org.apache.sshd.client.session.ClientSession#getKeyIdentityProvider return an
empty provider on 2.10.0 but not on 2.9.2 ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobiloc
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741536#comment-17741536
]
Tobias Gierke commented on SSHD-1329:
-
2.9.2
Call stack of *first* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider is this:
!image-2023-07-10-12-25-51-220.png!
Call stack of *second* invocation of
KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-24-22-392.png!
2.10.0
Call stack of only KeyIdentityProvider#resolveKeyIdentityProvider() is this:
!image-2023-07-10-12-28-40-339.png!
So while on 2.9.2 the second resolveIdentityProvider() call (triggered by the
messageReceived() method) does have a non-empty KeyIdentityProvider, 2.10.0
only calls resolveIdentityProvider() once (also from messageReceived()) but in
this case the KeyIdentityProvider is still empty.
So the questionnow is: Why does
org.apache.sshd.client.session.ClientSession#getKeyIdentityProvider return an
empty provider on 2.10.0 but not on 2.9.2 ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey []
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-28-40-339.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DE
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-25-51-220.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DE
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-24-22-392.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> d
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741535#comment-17741535
]
Tobias Gierke commented on SSHD-1329:
-
+2.9.2+
The MultiKeyIdentityProvider is created on the SECOND invocation of this method
in MultiKeyIdentityProvider (the first invocation has the
KeyIdentityProvider#EMPTY_KEYS_PROVIDER as "keys").
!image-2023-07-10-12-08-39-123.png!
+2.10.0+
The resolveKeyIdentityProvider() method is only called once (not twice as in
2.9.2) and just like on 2.9.2, the first invocation has
KeyIdentityProvider#EMPTY_KEYS_PROVIDER as "keys
So now the question is: Why is 2.10.0 not doing the second
resolveKeyIdentitiyProvider() call as 2.9.2 does ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial re
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-12-02-825.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSession
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-08-39-123.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741530#comment-17741530
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 10:05 AM:
---
The empty iterator on 2.10.0 is of type
org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator.
Stepping through the constructor of this class , I can see that on both 2.9.2
and 2.10.0 the initializeSessionIdentities() returns an Iterable that will
yield Iterators based on
ClientSession.providerOf(session).loadKeys(session)
!image-2023-07-10-12-04-00-532.png!
+2.9.2+
ClientSession.providerOf() returns a *MultiKeyIdentityProvider* with
!image-2023-07-10-11-56-35-508.png!
and the FileKeyPairProvider successfully loads the keys.
+2.10.0+
ClientSession.providerOf() returns a *AuthenticationIdentitiesProvider* only.
... so now the question is: Why doesn't return 2.10.0 return a
MultiKeyIdentityProvider as well ? More debugging...
was (Author: tgierke2342):
The empty iterator on 2.10.0 is of type
org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator.
Stepping through the constructor of this class , I can see that on both 2.9.2
and 2.10.0 the initializeSessionIdentities() returns an Iterable that will
yield Iterators based on
ClientSession.providerOf(session).loadKeys(session)
!image-2023-07-10-12-04-00-532.png!
+2.9.2+
ClientSession.providerOf() returns a *MultiKeyIdentityProvider* with
!image-2023-07-10-11-56-35-508.png!
and the FileKeyPairProvider successfully loads the keys.
+2.10.0+
ClientSession.providerOf() returns a
{*}AuthenticationIdentitiesProvider{*}{*}{*}
... so now the question is: Why doesn't return 2.10.0 return a
MultiKeyIdentityProvider as well ? More debugging...
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmt
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741530#comment-17741530
]
Tobias Gierke commented on SSHD-1329:
-
The empty iterator on 2.10.0 is of type
org.apache.sshd.client.auth.pubkey.UserAuthPublicKeyIterator.
Stepping through the constructor of this class , I can see that on both 2.9.2
and 2.10.0 the initializeSessionIdentities() returns an Iterable that will
yield Iterators based on
ClientSession.providerOf(session).loadKeys(session)
!image-2023-07-10-12-04-00-532.png!
+2.9.2+
ClientSession.providerOf() returns a *MultiKeyIdentityProvider* with
!image-2023-07-10-11-56-35-508.png!
and the FileKeyPairProvider successfully loads the keys.
+2.10.0+
ClientSession.providerOf() returns a
{*}AuthenticationIdentitiesProvider{*}{*}{*}
... so now the question is: Why doesn't return 2.10.0 return a
MultiKeyIdentityProvider as well ? More debugging...
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-12-04-00-532.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,5
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-11-56-35-508.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thre
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-11-54-05-391.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.
[jira] [Updated] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke updated SSHD-1329:
Attachment: image-2023-07-10-11-48-25-736.png
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> releaseKeys(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> closing
> UserAuthPublicKeyIterator[ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]]
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> destroy(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> 2023-06-19T13:13:41,533 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apa
[jira] [Comment Edited] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741507#comment-17741507
]
Tobias Gierke edited comment on SSHD-1329 at 7/10/23 9:33 AM:
--
Ok, back from vacation ... thanks for spending the time to try reproducing it
with Ubuntu 22.04.2 LTS ..
I've tried putting a breakpoint in
RSAPEMResourceKeyPairParser.extractKeyPairs() but this method is never hit,
neither on 2.9.2 nor on 2.10.0 - any advice where I could put a breakpoint
instead ?
Ok, I've put method-level breakpoints on all KeyPairResourceLoader interface
methods instead.
+2.9.2+
When stepping through the 2.9.2 code I can see that
org.apache.sshd.common.config.keys.loader.KeyPairResourceParser#loadKeyPairs is
being hit and inside it, only two parser instances registered:
- PEMResourceParserUtils#PROXY
-
org.apache.sshd.common.config.keys.loader.openssh.OpenSSHKeyPairResourceParser
The OpenSSHKeyPairResourceParser is the one being used on 2.9.2 and this is
what it returns:
!image-2023-07-10-11-16-03-470.png!
+2.10.0+
None of the KeyPairResourceLoader interface methods are being hit.
I've gone up the 2.9.2 call stack and the first method that was hit on both
2.9.2 and 2.10.0 was
org.apache.sshd.client.auth.pubkey.UserAuthPublicKey#resolveAttemptedPublicKeyIdentity
Stepping through that code shows that on 2.9.2, the "keys" iterator returns
elements while on 2.10.0 the iterator is empty so the while body is never
executed.
!image-2023-07-10-11-31-54-206.png!
Now I remember that this was what actually led me to filing this ticket in the
first place ... I was not able to debug where this iterator was coming from
(too many indirections for my tiny brain).
was (Author: tgierke2342):
Ok, back from vacation ... thanks for spending the time to try reproducing it
with Ubuntu 22.04.2 LTS ..
I've tried putting a breakpoint in
RSAPEMResourceKeyPairParser.extractKeyPairs() but this method is never hit,
neither on 2.9.2 nor on 2.10.0 - any advice where I could put a breakpoint
instead ?
I've put method-level breakpoints on all KeyPairResourceLoader interface
methods instead.
+2.9.2+
When stepping through the 2.9.2 code I can see that
org.apache.sshd.common.config.keys.loader.KeyPairResourceParser#loadKeyPairs is
being hit and inside it, only two parser instances registered:
- PEMResourceParserUtils#PROXY
- org.apache.sshd.common.config.keys.loader.openssh.OpenSSHKeyPairResourceParser
The OpenSSHKeyPairResourceParser is the one being used on 2.9.2 and this is
what it returns:
!image-2023-07-10-11-16-03-470.png!
+2.10.0+
None of the KeyPairResourceLoader interface methods are being hit.
I've gone up the 2.9.2 call stack and the first method that was hit on both
2.9.2 and 2.10.0 was
org.apache.sshd.client.auth.pubkey.UserAuthPublicKey#resolveAttemptedPublicKeyIdentity
Stepping through that code shows that on 2.9.2, the "keys" iterator returns
elements while on 2.10.0 the iterator is empty so the while body is never
executed.
!image-2023-07-10-11-31-54-206.png!
Now I remember that this was what actually led me to filing this ticket in the
first place ... I was not able to debug where this iterator was coming from
(too many indirections for my tiny brain).
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-
