[jira] [Updated] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[ https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Holger Rehn updated SSHD-998: - Description: Even if using an SftpVersionSelector (e.g. created by SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. This behaviour is hard-coded and may cause problems if the server doesn't correctly handle the request/support protocol version 6. One of our customers is using a server that initially accepts protocol version 6, but then fails every single request by sending invalid data. Actually, the server only correctly supports SFTP 3, so this clearly is a bug in the server implementation - but could be circumvented quite easily by starting with protocol version 3. Furthermore an additional (and actually unnecessary) version renegotiation may be required later. If using an SftpVersionSelector that prefers a certain protocol version other than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), an additional (and actually unnecessary) network round trip is required for protocol version renegotiation. Please find attached a minimally invasive patch against the official 2.4.0 source to respect the version(s) accepted by an SftpVersionSelector for choosing the initial protocol version. was: Even if using an SftpVersionSelector (e.g. created by SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. This behaviour is hard-coded and may cause problems if the server doesn't correctly handle the request/support protocol version 6. One of our customers is using a server that initially accepts protocol version 6, but then fails every single request by sending invalid data. Actually, the server only correctly supports SFTP 3, so this clearly is a bug in the server implementation - but could be circumvented quite easily by starting with protocol version 3. Furthermore an additional (and actually unnecessary) version renegotiation may be required later. If using an SftpVersionSelector that prefers a certain protocol version other than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), an additional (and actually unnecessary) network round trip is required for protocol version renegotiation. Please find attached a minimally invative patch against the official 2.4.0 source to respect the version(s) accepted by an SftpVersionSelector for choosing the initial protocol version. > respect SftpVersionSelector when establishing a new connection > -- > > Key: SSHD-998 > URL: https://issues.apache.org/jira/browse/SSHD-998 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Holger Rehn >Priority: Major > Labels: features, patch, performance > Attachments: patch.diff > > > Even if using an SftpVersionSelector (e.g. created by > SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol > version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. > This behaviour is hard-coded and may cause problems if the server doesn't > correctly handle the request/support protocol version 6. One of our customers > is using a server that initially accepts protocol version 6, but then fails > every single request by sending invalid data. Actually, the server only > correctly supports SFTP 3, so this clearly is a bug in the server > implementation - but could be circumvented quite easily by starting with > protocol version 3. Furthermore an additional (and actually unnecessary) > version renegotiation may be required later. > If using an SftpVersionSelector that prefers a certain protocol version other > than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), > an additional (and actually unnecessary) network round trip is required for > protocol version renegotiation. > > Please find attached a minimally invasive patch against the official 2.4.0 > source to respect the version(s) accepted by an SftpVersionSelector for > choosing the initial protocol version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (SSHD-998) respect SftpVersionSelector when establishing a new connection
Holger Rehn created SSHD-998: Summary: respect SftpVersionSelector when establishing a new connection Key: SSHD-998 URL: https://issues.apache.org/jira/browse/SSHD-998 Project: MINA SSHD Issue Type: Bug Affects Versions: 2.4.0 Reporter: Holger Rehn Attachments: patch.diff Even if using an SftpVersionSelector (e.g. created by SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. This behaviour is hard-coded and may cause problems if the server doesn't correctly handle the request/support protocol version 6. One of our customers is using a server that initially accepts protocol version 6, but then fails every single request by sending invalid data. Actually, the server only correctly supports SFTP 3, so this clearly is a bug in the server implementation - but could be circumvented quite easily by starting with protocol version 3. Furthermore an additional (and actually unnecessary) version renegotiation may be required later. If using an SftpVersionSelector that prefers a certain protocol version other than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), an additional (and actually unnecessary) network round trip is required for protocol version renegotiation. Please find attached a minimally invative patch against the official 2.4.0 source to respect the version(s) accepted by an SftpVersionSelector for choosing the initial protocol version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109606#comment-17109606
]
Matt Sicker edited comment on SSHD-506 at 5/17/20, 6:44 PM:
I decided to cheat a little and go read the source code in OpenSSH. I think
it's given me a couple ideas on refactoring what I've written to better match
how they implement this. It seems like any implementation of SSH follows a
fairly similar architecture that mirrors the SSH standard, and that has made it
increasingly easy for me to jump around all these different implementations.
Due to a limitation in the Java crypto API, I'll have to keep track of the
secret key when using GCM so I can re-init the cipher with the updated IV on
each packet (OpenSSL apparently allows you to directly update an IV using the
envelope cipher function for setting an IV; yay for low level operations we
can't access). And as far as I can tell, OpenSSH seems to use the IV as
calculated during key exchange, and then it updates the IV for each packet by
incrementing the 8 upper bytes as an unsigned long (the lower 4 bytes remain
fixed until a re-key).
Based on my read through so far, I think I've got this mostly figured out. I
think I initially confused a couple things: how to update the nonce properly
for OpenSSH compatibility, and how to treat the packet length in this mode
(this is more of an "off by 4" error rather than "off by 1").
Finally, some good news: the use of AES/GCM in the RFC works naturally with how
the Java API works (appending the authentication tag (AT) after the ciphertext
automatically), and the processing of the packet length group of bytes
basically gets changed from calling {{update}} to {{updateAAD}} to leave it
unencrypted but still calculated in the AT. The only API mis-match is the
aforementioned inability to directly update the IV of a cipher without
re-initializing it with the key as well. To avoid re-computing the key on every
packet, I'll have to cache it.
was (Author: jvz):
I decided to cheat a little and go read the source code in OpenSSH. I think
it's given me a couple ideas on refactoring what I've written to better match
how they implement this. It seems like any implementation of SSH follows a
fairly similar architecture that mirrors the SSH standard, and that has made it
increasingly easy for me to jump around all these different implementations.
Due to a limitation in the Java crypto API, I'll have to keep track of the
secret key when using GCM so I can re-init the cipher with the updated IV on
each packet (OpenSSL apparently allows you to directly update an IV using the
envelope cipher function for setting an IV; yay for low level operations we
can't access). And as far as I can tell, OpenSSH seems to use the IV as
calculated during key exchange, and then it updates the IV for each packet by
incrementing the 8 upper bytes as an unsigned long (the lower 4 bytes remain
fixed until a re-key).
Based on my read through so far, I think I've got this mostly figured out. I
think I initially confused a couple things: how to update the nonce properly
for OpenSSH compatibility, and how to treat the packet length in this mode
(this is more of an "off by 4" error rather than "off by 1").
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109606#comment-17109606
]
Matt Sicker commented on SSHD-506:
--
I decided to cheat a little and go read the source code in OpenSSH. I think
it's given me a couple ideas on refactoring what I've written to better match
how they implement this. It seems like any implementation of SSH follows a
fairly similar architecture that mirrors the SSH standard, and that has made it
increasingly easy for me to jump around all these different implementations.
Due to a limitation in the Java crypto API, I'll have to keep track of the
secret key when using GCM so I can re-init the cipher with the updated IV on
each packet (OpenSSL apparently allows you to directly update an IV using the
envelope cipher function for setting an IV; yay for low level operations we
can't access). And as far as I can tell, OpenSSH seems to use the IV as
calculated during key exchange, and then it updates the IV for each packet by
incrementing the 8 upper bytes as an unsigned long (the lower 4 bytes remain
fixed until a re-key).
Based on my read through so far, I think I've got this mostly figured out. I
think I initially confused a couple things: how to update the nonce properly
for OpenSSH compatibility, and how to treat the packet length in this mode
(this is more of an "off by 4" error rather than "off by 1").
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109564#comment-17109564
]
Matt Sicker commented on SSHD-506:
--
Yup, it's not as simple an update as some of the other SSH RFCs. Thus, it has
taken longer than a day for a proof of concept (I still seem to have a few off
by 1-ish errors in my modifications right now), but I hope to figure it out
with some added logging to figure out what I'm doing wrong.
There is one particularly tricky design issue here with the Mina interface for
Cipher. In order to use GCM, we need to finalize and initialize the cipher at
the end of each packet. The other modes never finalize the cipher until a rekey
event takes place (which it still technically never calls {{doFinal}}), thus no
new IVs are ever needed until said rekey event. In GCM, we need to
re-initialize the cipher for each packet with the appropriate nonce/IV. Based
on my reading of the standard, what I think happens is that we use the agreed
upon IVs as our initial nonce, but then we overwrite the invocation counter
octets with the corresponding packet sequence number. Once I can get something
working in a unit test at least, I can then try it out with OpenSSH to verify
my assumptions.
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109548#comment-17109548
]
Lyor Goldstein commented on SSHD-506:
-
You have nailed the problem - I would have liked to add these ciphers, but it
requires major overhaul to the packet encoding/decoding mechanism.
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109547#comment-17109547
]
Matt Sicker commented on SSHD-506:
--
FYI, I'm working on a patch for this as part of some side work I'm doing to
evaluate using this library as a long term replacement for Trilead/Ganymede and
JSch in Jenkins as well as part of a presentation I'm putting together about
modern crypto (primarily AES/GCM, though I was hoping I'd be able to cover a
couple more algorithms in the talk). This has turned out to be slightly more
complicated than expected since the binary packet protocol is slightly modified
compared to ETM modes.
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109541#comment-17109541
]
Lyor Goldstein commented on SSHD-997:
-
Perhaps a more appropriate approach would be to examine and fix
{quote}
Both also compare the seed of the private key, but for a generated key, this is
some random value, while it is all zeroes for a key read from a file.
{quote}
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109540#comment-17109540
]
Lyor Goldstein commented on SSHD-997:
-
I have looked over the code and it does not seem to be proper replacement - it
lacks the necessary classes required to allows us to use it as a
{{SecurityProvider}}. Furthermore it's keys do not properly implement
{{java.security.Private/PublicKey}} and/or {{java.security.Signature}}. Until
it does, I don't think we can afford to write our own provider wrapper for
it
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Major
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
[
https://issues.apache.org/jira/browse/SSHD-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-997:
Priority: Minor (was: Major)
> Replace EdDSA-Java library with new ed25519-elisabeth implementation
>
>
> Key: SSHD-997
> URL: https://issues.apache.org/jira/browse/SSHD-997
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> Recent addition to the SSHD library revealed issues with seed attribute in
> EdDSA-Java library:
> {code:java}
> +private boolean compare(KeyPair a, KeyPair b) {
> +if ("EDDSA".equals(data.algorithm)) {
> +// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
> +// seed of the private key, but for a generated key, this is some
> +// random value, while it is all zeroes for a key read from a
> file.
> +return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
> +&& Objects.equals(((EdDSAKey)
> a.getPrivate()).getParams(),
> +((EdDSAKey) b.getPrivate()).getParams());
> +}
> {code}
> The corresponding issue: [1] upstream pointing to the new library:
> [1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
> [2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-995) Custom user defined Exception ,message need to send
[
https://issues.apache.org/jira/browse/SSHD-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein closed SSHD-995.
---
Resolution: Not A Problem
> Custom user defined Exception ,message need to send
> ---
>
> Key: SSHD-995
> URL: https://issues.apache.org/jira/browse/SSHD-995
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Sandeep
>Priority: Blocker
> Attachments: image-2020-05-16-12-24-44-502.png
>
>
> I need to send Exception message to user. Example
> {code:java}
> throws IOException("this is test message i need to send back instead of
> default predefined message");{code}
>
> I do not want this predefined messages.
> !image-2020-05-16-12-24-44-502.png!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-996) Fetch Public Key from remote server
[
https://issues.apache.org/jira/browse/SSHD-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-996.
-
Resolution: Not A Problem
Please use the d...@mina.apache.org.il mailing list for such questions since
these are not real issues. I just answered such a question - see code in
{{SshKeyScanMain}} class
> Fetch Public Key from remote server
> ---
>
> Key: SSHD-996
> URL: https://issues.apache.org/jira/browse/SSHD-996
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.3.0
>Reporter: Nilesh
>Priority: Blocker
>
> I am working on to fetch public key from the remote server.
> Users can verify the identity of the server (by checking the public key)
> during the initial protocol negotiation.
> I am not able to get the public key from the remote server.
> Code snippet:
> ServerKeyVerifier serverky=session.getServerKeyVerifier();
> PublicKey pk= session.getKex().getServerKey(); // Not working
> Above solution not working then I am trying to use
> KnownHostsServerKeyVerifier.jav to get the publicKey but could not able to do
> .
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109536#comment-17109536
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
Server-side, I still get the deadlock, and it still there ~30min later.
{quote}
Is it the same flow or some new deadlock ? Can we tell in any way ?
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
Re: SSHD Mina: Help to fetch public key from host
>> I have one requirement where I have to fetch public key from given remote host and port, Can you please help me for that, Please point me for any document, code snippet. There is class that I believe already does this: see SshKeyScanMain
[jira] [Created] (SSHD-997) Replace EdDSA-Java library with new ed25519-elisabeth implementation
David Ostrovsky created SSHD-997:
Summary: Replace EdDSA-Java library with new ed25519-elisabeth
implementation
Key: SSHD-997
URL: https://issues.apache.org/jira/browse/SSHD-997
Project: MINA SSHD
Issue Type: New Feature
Affects Versions: 2.4.0
Reporter: David Ostrovsky
Recent addition to the SSHD library revealed issues with seed attribute in
EdDSA-Java library:
{code:java}
+private boolean compare(KeyPair a, KeyPair b) {
+if ("EDDSA".equals(data.algorithm)) {
+// Bug in net.i2p.crypto.eddsa and in sshd? Both also compare the
+// seed of the private key, but for a generated key, this is some
+// random value, while it is all zeroes for a key read from a file.
+return KeyUtils.compareKeys(a.getPublic(), b.getPublic())
+&& Objects.equals(((EdDSAKey) a.getPrivate()).getParams(),
+((EdDSAKey) b.getPrivate()).getParams());
+}
{code}
The corresponding issue: [1] upstream pointing to the new library:
[1] https://github.com/str4d/ed25519-java/issues/30#issuecomment-573389252
[2] https://github.com/cryptography-cafe/ed25519-elisabeth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
