[jira] [Commented] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560 ] Lyor Goldstein commented on SSHD-974: - Yes, I just confirmed it - the problem you describe occurs if eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing this problem and re-open the issue if it still occurs. > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford >Assignee: Lyor Goldstein >Priority: Minor > Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, > id_ed25519.pub.hex > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- 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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-974. - Resolution: Invalid > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford >Assignee: Lyor Goldstein >Priority: Minor > Attachments: 105624.png, Main.java, error.log, id_ed25519.pub, > id_ed25519.pub.hex > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- 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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077560#comment-17077560
]
Lyor Goldstein edited comment on SSHD-974 at 4/7/20, 8:46 PM:
--
Yes, I just confirmed it - the problem you describe occurs if
{{eddsa-0.3.0.jar}} is not on your CLASSPATH. Please try it after fixing this
problem and re-open the issue if it still occurs.
was (Author: lgoldstein):
Yes, I just confirmed it - the problem you describe occurs if
eddsa-0.3.0.jar}} is not}} on your CLASSPATH. Please try it after fixing
this problem and re-open the issue if it still occurs.
> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: 105624.png, Main.java, error.log, id_ed25519.pub,
> id_ed25519.pub.hex
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with
> the error message "Bad format (no key data delimiter)" however this key is
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.
--
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-976) Add support for RSASSA-PSS keys
[ https://issues.apache.org/jira/browse/SSHD-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-976: Description: See [a|https://tools.ietf.org/html/rfc4056]ttached links (was: See [https://tools.ietf.org/html/rfc4056]) > Add support for RSASSA-PSS keys > --- > > Key: SSHD-976 > URL: https://issues.apache.org/jira/browse/SSHD-976 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Lyor Goldstein >Priority: Minor > > See [a|https://tools.ietf.org/html/rfc4056]ttached links -- 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-976) Add support for RSASSA-PSS keys
Lyor Goldstein created SSHD-976: --- Summary: Add support for RSASSA-PSS keys Key: SSHD-976 URL: https://issues.apache.org/jira/browse/SSHD-976 Project: MINA SSHD Issue Type: New Feature Reporter: Lyor Goldstein See [https://tools.ietf.org/html/rfc4056] -- 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-977) Apply consistent logging policy to caught exceptions
Lyor Goldstein created SSHD-977: --- Summary: Apply consistent logging policy to caught exceptions Key: SSHD-977 URL: https://issues.apache.org/jira/browse/SSHD-977 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein Assignee: Lyor Goldstein See [https://github.com/apache/mina-sshd/pull/120] as an example: * Log at ERROR/WARNING level the basic exception details (class + message) * If DEBUG enabled then also log at ERROR/WARNING level the actual stack trace -- 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] [Work started] (SSHD-977) Apply consistent logging policy to caught exceptions
[ https://issues.apache.org/jira/browse/SSHD-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-977 started by Lyor Goldstein. --- > Apply consistent logging policy to caught exceptions > > > Key: SSHD-977 > URL: https://issues.apache.org/jira/browse/SSHD-977 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Major > > See [https://github.com/apache/mina-sshd/pull/120] as an example: > * Log at ERROR/WARNING level the basic exception details (class + message) > * If DEBUG enabled then also log at ERROR/WARNING level the actual stack trace -- 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-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088664#comment-17088664 ] Lyor Goldstein commented on SSHD-981: - Great - thanks > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.5.0 > > > This extension has been specified by [https://tools.ietf.org/html/rfc8308] -- 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-981) Implement no-flow-control SFTP extension
[ https://issues.apache.org/jira/browse/SSHD-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087054#comment-17087054 ] Lyor Goldstein commented on SSHD-981: - Can you add a link to some documentation as to these extensions specifications ? > Implement no-flow-control SFTP extension > > > Key: SSHD-981 > URL: https://issues.apache.org/jira/browse/SSHD-981 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.4.1 > > -- 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-895) Add support for RSA + SHA-256/512 signatures
[
https://issues.apache.org/jira/browse/SSHD-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087035#comment-17087035
]
Lyor Goldstein commented on SSHD-895:
-
{quote}m.. if it is like this, would it not get really worse if we add all the
*-cert algorithms in SSHD-660?{quote}
It would - we just need to make sure they are added only on the +server+ side -
on the client side they will require +explicit+ setting
{quote}users are still able to disable this in case they encounter such a
server?{quote}
They would - they can +explicitly+ set the supported algorithms on the client
side
> Add support for RSA + SHA-256/512 signatures
>
>
> Key: SSHD-895
> URL: https://issues.apache.org/jira/browse/SSHD-895
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.3.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>
> See https://tools.ietf.org/html/rfc8332 - *Note:*
> {quote}
> Servers that accept rsa-sha2-* signatures for client authentication
> SHOULD implement the extension negotiation mechanism defined in
> [RFC8308], including especially the "server-sig-algs" extension.
> {quote}
--
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-660) Add support for authentication using signed client/server keys
[ https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-660. - Fix Version/s: 2.4.1 Resolution: Fixed > Add support for authentication using signed client/server keys > -- > > Key: SSHD-660 > URL: https://issues.apache.org/jira/browse/SSHD-660 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Priority: Minor > Fix For: 2.4.1 > > > Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - > see https://ef.gy/hardening-ssh -- 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-977) Apply consistent logging policy to caught exceptions
[ https://issues.apache.org/jira/browse/SSHD-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-977. - Fix Version/s: 2.4.1 Resolution: Fixed > Apply consistent logging policy to caught exceptions > > > Key: SSHD-977 > URL: https://issues.apache.org/jira/browse/SSHD-977 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.4.1 > > > See [https://github.com/apache/mina-sshd/pull/120] as an example: > * Log at ERROR/WARNING level the basic exception details (class + message) > * If DEBUG enabled then also log at ERROR/WARNING level the actual stack trace -- 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-660) Add support for authentication using signed client/server keys
[
https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17084583#comment-17084583
]
Lyor Goldstein edited comment on SSHD-660 at 4/16/20, 7:08 AM:
---
{quote}
For the unit tests I don't really know how and what is best to test.. Are there
some integration tests which I overlook? Would be the easiest to spawn a server
and let a client ping?
{quote}
For unit testing it is enough to spawn a server and let a client ping - there
are plenty of examples in the current code how to do this.
{quote}
I tested it against `OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep
2019` (default Debian Buster) and with `OpenSSH_8.1p1, LibreSSL 2.7.3` (default
macOS) client.
{quote}
Can you provide some reference documentation how to set up these servers to
execute this type of authentication ?
was (Author: lgoldstein):
{quote}
For the unit tests I don't really know how and what is best to test.. Are there
some integration tests which I overlook? Would be the easiest to spawn a server
and let a client ping?
{quote}
For unit testing it is enough to spawn a server and let a client ping - there
are plenty of examples in the current code how to do this.
{quote}
I tested it against `OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep
2019` (default Debian Buster) and with `OpenSSH_8.1p1, LibreSSL 2.7.3` (default
macOS) client.
{quote}
Can you provide some reference documentation how to set up these server to
execute this type of authentication ?
> Add support for authentication using signed client/server keys
> --
>
> Key: SSHD-660
> URL: https://issues.apache.org/jira/browse/SSHD-660
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Minor
>
> Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values -
> see https://ef.gy/hardening-ssh
--
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-660) Add support for authentication using signed client/server keys
[ https://issues.apache.org/jira/browse/SSHD-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075174#comment-17075174 ] Lyor Goldstein commented on SSHD-660: - The link you provided adds some information, but it is not the main problem. The issue here is that I expect implementing the feature would require a significant amount of time - something we are very short of. Therefore, we try and invest the little time we have on bug fixes and widely used features - this does not seem to be one. Furthermore, even if we had the time, we still need a client/server that also also support this feature so we can check for interoperability - something I have not been able to find. Therefore, unfortunately I don't see us getting around to it any time soon (unless it suddenly becomes in high demand). That being said, we always welcome contributions - so if you would like to undertake to implement this feature I would be happy to assist with advice and pointers for issues you may encounter. > Add support for authentication using signed client/server keys > -- > > Key: SSHD-660 > URL: https://issues.apache.org/jira/browse/SSHD-660 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Lyor Goldstein >Priority: Minor > > Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - > see https://ef.gy/hardening-ssh -- 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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069929#comment-17069929
]
Lyor Goldstein commented on SSHD-974:
-
{quote}
I can generate a new key pair and test that it triggers the bug if you need the
private key as well
{quote}
No thanks - the file is enough...
> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java, error.log, id_ed25519.pub
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with
> the error message "Bad format (no key data delimiter)" however this key is
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.
--
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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[
https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070388#comment-17070388
]
Lyor Goldstein commented on SSHD-974:
-
Are you sure about the problem ? I am running your code against the file you
attached and I am getting no exception. If on your environment you can
reproduce the issue consistently, then I suggest the following:
* Place a debug breakpoint in {{AuthorizedKeyEntry#parseAuthorizedKeyEntry}}
method at line 293 where the exception is thrown
* Run your code
* Assuming the breakpoint is hit, examine the _value_ and _line_ variables -
look specifically for any non-space characters after the {{ssh-ed25519}} part -
e.g., Unicode, tab, backspace, etc
I strongly suspect that the file you have attached is not an exact copy of the
file that is causing the problem and that there is some "hidden" character in
the file that is causing the problem. Therefore, if you could attach a
_hexdump_ of the file that is causing the problem it would help better diagnose
the problem.
> AuthorizedKeyEntry fails to parse ed25519 public keys
> -
>
> Key: SSHD-974
> URL: https://issues.apache.org/jira/browse/SSHD-974
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
> Environment: Arch Linux compiled with OpenJDK 1.8.0_242
>Reporter: Justin Crawford
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java, error.log, id_ed25519.pub
>
>
> When parsing an authorized keys file, I get a StreamCorruptedException with
> the error message "Bad format (no key data delimiter)" however this key is
> accepted by OpenSSH and generated by ssh-keygen. Other key types, such as
> RSA, are parsed just fine by this parser.
> I attached an example program demonstrating how I am using the parser.
--
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] [Assigned] (SSHD-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-974: --- Assignee: Lyor Goldstein > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford >Assignee: Lyor Goldstein >Priority: Minor > Attachments: Main.java, error.log > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- 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-974) AuthorizedKeyEntry fails to parse ed25519 public keys
[ https://issues.apache.org/jira/browse/SSHD-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068864#comment-17068864 ] Lyor Goldstein commented on SSHD-974: - Can you attach the original file from which this error originated ? I suspect there might be some hidden character there... > AuthorizedKeyEntry fails to parse ed25519 public keys > - > > Key: SSHD-974 > URL: https://issues.apache.org/jira/browse/SSHD-974 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 > Environment: Arch Linux compiled with OpenJDK 1.8.0_242 >Reporter: Justin Crawford >Assignee: Lyor Goldstein >Priority: Minor > Attachments: Main.java, error.log > > > When parsing an authorized keys file, I get a StreamCorruptedException with > the error message "Bad format (no key data delimiter)" however this key is > accepted by OpenSSH and generated by ssh-keygen. Other key types, such as > RSA, are parsed just fine by this parser. > I attached an example program demonstrating how I am using the parser. -- 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=17066540#comment-17066540
]
Lyor Goldstein commented on SSHD-966:
-
I will take a closer look at the suggestion but from my initial review it looks
a lot like what I was trying to do when I spoke too soon about having found a
solution. The problem remains the same - if there is enough traffic then the
KEX state remains FLUSHING. Furthermore, the traffic is slowed down
significantly since all packets must be queued and then dequeued and sent via
{{synchronized}} mechanisms.
Moreover, some code might actually rely on the {{IoWriteFuture}} returned from
{{writePacket}} - in which case we need to establish some equivalent (IMO
complex) mechanism.
Last but not least - introducing a new KEX state to what already is a complex
state machine is likely to introduce bugs and destabilize the code.
You have given me some ideas to explore though - perhaps one of them will pan
out. Thanks for the response.
> 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: 10m
> 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)
>
[jira] [Commented] (SSHD-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094592#comment-17094592
]
Lyor Goldstein commented on SSHD-984:
-
Then attach the ZIP and I will see if I can find a home for it in the SSHD tree
- then suggest it to you so we can have a PR over which we can discuss the
code. Alternatively, I am OK with placing the code under the
{{org.apache.sshd.common.config.keys.loader.openssh}} package for now and then
re-factor it as needed.
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094579#comment-17094579
]
Lyor Goldstein commented on SSHD-984:
-
{quote}
I have whipped up a fairly complete prototype including a minimal test for
doing this (both writing PKCS#8 PEM files and the modern OpenSSH files with
bcrypt KDF), but it's not in a state that it could be integrated easily into
sshd.
I could provide you that code; shall I attach a zip here?
{quote}
Can you open up a PR (even though "not in a state that it could be integrated
easily into sshd.") ? I find it easier to review code in that format - not to
mention the fact that we can discuss it as it progresses.
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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-985) Support Bouncy Castle Ed25519 and Ed448 keys
[
https://issues.apache.org/jira/browse/SSHD-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094570#comment-17094570
]
Lyor Goldstein commented on SSHD-985:
-
If we do that then need to see if can also remove dependency on {{net.i2p}}
> Support Bouncy Castle Ed25519 and Ed448 keys
>
>
> Key: SSHD-985
> URL: https://issues.apache.org/jira/browse/SSHD-985
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Priority: Minor
>
> Bouncy Castle nowadays (at least since 1.64) also has an EDDSA provider. Sshd
> should be able to work with those keys, too, not just with the ones from
> net.i2p.crypto.eddsa.
> One notable difference is that net.i2p produces keys that return from
> Key.getAlgorithm() "EdDSA", while the Bouncy Castle keys return "Ed25519" or
> "Ed448", respectively.
--
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-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094564#comment-17094564
]
Lyor Goldstein commented on SSHD-984:
-
Seems like a valid request - until now our policy was that key files are
generated by external tools. I will look into the possibility of using
_Bouncycastle_ if possible. If so, it still trades one dependency (_jsch_) with
another (_bouncycastle_) though I guess it still better than having both...
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094592#comment-17094592
]
Lyor Goldstein edited comment on SSHD-984 at 4/28/20, 3:15 PM:
---
Then attach the ZIP and I will see if I can find a home for it in the SSHD tree
- then suggest it to you so we can have a PR over which we can discuss the
code. Alternatively, I am OK with placing the code under the
{{org.apache.sshd.common.config.keys.loader.openssh}} package for now and then
re-factor it as needed.
In any case, since you are already working on it I rely on your discretion to
decide when you think it is ready for some initial review and/or discussion.
was (Author: lgoldstein):
Then attach the ZIP and I will see if I can find a home for it in the SSHD tree
- then suggest it to you so we can have a PR over which we can discuss the
code. Alternatively, I am OK with placing the code under the
{{org.apache.sshd.common.config.keys.loader.openssh}} package for now and then
re-factor it as needed.
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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-983) mina sshd create file system error
[
https://issues.apache.org/jira/browse/SSHD-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092545#comment-17092545
]
Lyor Goldstein commented on SSHD-983:
-
It does not look like a regular MINA-SSHD code used to create a file system but
rather more like some reverse engineering that is trying to access only some
select sections of the code rather than use it in a normal manner - so I don't
think I can do much. That being said, a quick overview of the code shows the
problem - the {{DefaultSftpClient}} constructor issues {{SSH_FXP_INIT}} and
expects to receive a response with a valid version from the server - something
that does not occur on time. Most likely, the code skipped some vital
initialization that is usually executed by the regular code.
> mina sshd create file system error
> --
>
> Key: SSHD-983
> URL: https://issues.apache.org/jira/browse/SSHD-983
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 1.7.0
>Reporter: barry-gq
>Priority: Major
> Attachments: image-2020-04-26-11-14-30-914.png
>
>
> i use mina-sshd sftp to create a file system，and use filezilla to connect a
> suselinux（version：11），but there was an error（If you don't pass my code, it
> can connect successfully）
>
> 2020-04-24 16:09:43.069 [WARN ] [sshd-SshServer[7b61bf11]-nio2-thread-3]
> [org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClient::lambda$0]
> [TxId:,SpanId:] onClose(ChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[etl@/88.0.62.70:22][sftp]) closed before
> version negotiated
> Failed to create file system
> java.net.SocketTimeoutException: No incoming initialization response received
> within 15000 msec.java.net.SocketTimeoutException: No incoming initialization
> response received within 15000 msec. at
> org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClient.init(DefaultSftpClient.java:369)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClient.(DefaultSftpClient.java:110)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClientFactory.createDefaultSftpClient(DefaultSftpClientFactory.java:67)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.subsystem.sftp.impl.DefaultSftpClientFactory.createSftpClient(DefaultSftpClientFactory.java:47)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.session.AbstractClientSession.createSftpClient(AbstractClientSession.java:355)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.subsystem.sftp.SftpFileSystem.getClient(SftpFileSystem.java:158)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.client.subsystem.sftp.SftpFileSystem.(SftpFileSystem.java:79)
> ~[sshd-core.jar:1.7.0] at
> com.shterm.text.sftp.ShtermSftpFileSystem.(SourceFile:38)
> ~[shterm-text.jar:3.3.8] at
> com.shterm.text.sftp.ShtermFileSystemFactory.a(SourceFile:175)
> ~[shterm-text.jar:3.3.8] at
> com.shterm.text.sftp.ShtermFileSystemFactory.createFileSystem(SourceFile:78)
> ~[shterm-text.jar:3.3.8] at
> org.apache.sshd.server.channel.ChannelSession.prepareCommand(ChannelSession.java:644)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.server.channel.ChannelSession.prepareChannelCommand(ChannelSession.java:580)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.server.channel.ChannelSession.handleSubsystem(ChannelSession.java:576)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.server.channel.ChannelSession.handleInternalRequest(ChannelSession.java:312)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.channel.AbstractChannel.handleUnknownChannelRequest(AbstractChannel.java:321)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.channel.AbstractChannel.handleChannelRequest(AbstractChannel.java:308)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.channel.AbstractChannel.handleRequest(AbstractChannel.java:270)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelRequest(AbstractConnectionService.java:517)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:341)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:614)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:547)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1498)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:508)
> ~[sshd-core.jar:1.7.0] at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:66)
> ~[sshd-core.jar:1.7.0] at
>
[jira] [Resolved] (SSHD-982) Race condition when loading known hosts
[ https://issues.apache.org/jira/browse/SSHD-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-982. - Fix Version/s: 2.5.0 Resolution: Fixed > Race condition when loading known hosts > --- > > Key: SSHD-982 > URL: https://issues.apache.org/jira/browse/SSHD-982 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: FliegenKLATSCH >Priority: Minor > Fix For: 2.5.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > When multiple (client) connections are instantiated in parallel the loaded > known hosts collection might be empty and therefore host key verification > fails. -- 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-987) AESPrivateKeyObfuscator generates wrong IV length
[
https://issues.apache.org/jira/browse/SSHD-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095590#comment-17095590
]
Lyor Goldstein commented on SSHD-987:
-
[~wolft] thanks for the bug detection - see attached PR. If you have code that
uses it and would like to also test the code then see
https://github.com/lgoldstein/mina-sshd/tree/SSHD-987 (or you trust the unit
test for it...)
> AESPrivateKeyObfuscator generates wrong IV length
> -
>
> Key: SSHD-987
> URL: https://issues.apache.org/jira/browse/SSHD-987
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{AESPrivateKeyObfuscator.generateInitializationVector()}} inherited from
> {{AbstractPrivateKeyObfuscator}} produces IVs of length {{keyLength /
> Byte.SIZE}}.
> This works only for AES 128, but not for AES 192 or AES 256. The IV length
> for AES is 16.
> Compare also SSHD-873.
--
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] [Work started] (SSHD-987) AESPrivateKeyObfuscator generates wrong IV length
[
https://issues.apache.org/jira/browse/SSHD-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-987 started by Lyor Goldstein.
---
> AESPrivateKeyObfuscator generates wrong IV length
> -
>
> Key: SSHD-987
> URL: https://issues.apache.org/jira/browse/SSHD-987
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
>
> {{AESPrivateKeyObfuscator.generateInitializationVector()}} inherited from
> {{AbstractPrivateKeyObfuscator}} produces IVs of length {{keyLength /
> Byte.SIZE}}.
> This works only for AES 128, but not for AES 192 or AES 256. The IV length
> for AES is 16.
> Compare also SSHD-873.
--
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] [Assigned] (SSHD-987) AESPrivateKeyObfuscator generates wrong IV length
[
https://issues.apache.org/jira/browse/SSHD-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-987:
---
Assignee: Lyor Goldstein
> AESPrivateKeyObfuscator generates wrong IV length
> -
>
> Key: SSHD-987
> URL: https://issues.apache.org/jira/browse/SSHD-987
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
>
> {{AESPrivateKeyObfuscator.generateInitializationVector()}} inherited from
> {{AbstractPrivateKeyObfuscator}} produces IVs of length {{keyLength /
> Byte.SIZE}}.
> This works only for AES 128, but not for AES 192 or AES 256. The IV length
> for AES is 16.
> Compare also SSHD-873.
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095591#comment-17095591
]
Lyor Goldstein commented on SSHD-986:
-
Good questions + sample code - will have to think about it. It may take some
time though - as of next week I will be rather busy for some time...
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095591#comment-17095591
]
Lyor Goldstein edited comment on SSHD-986 at 4/29/20, 4:19 PM:
---
Good questions + sample code - will have to think about it. It may take some
time though - as of next week I will be rather busy for some time...
Meanwhile here is something I have considered - we can split the code in
{{PKCS8PEMResourceKeyPairParser#extractKeyPairs}} so that after it extracts the
private key, it calls a protected method to extract the public key. By default,
the protected method calls {{KeyUtils.recoverPublicKey(prvKey)}} unless it
detects ECDSA key OID and then it calls some TBD method...
was (Author: lgoldstein):
Good questions + sample code - will have to think about it. It may take some
time though - as of next week I will be rather busy for some time...
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-987) AESPrivateKeyObfuscator generates wrong IV length
[
https://issues.apache.org/jira/browse/SSHD-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-987.
-
Fix Version/s: 2.5.0
Resolution: Fixed
> AESPrivateKeyObfuscator generates wrong IV length
> -
>
> Key: SSHD-987
> URL: https://issues.apache.org/jira/browse/SSHD-987
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{AESPrivateKeyObfuscator.generateInitializationVector()}} inherited from
> {{AbstractPrivateKeyObfuscator}} produces IVs of length {{keyLength /
> Byte.SIZE}}.
> This works only for AES 128, but not for AES 192 or AES 256. The IV length
> for AES is 16.
> Compare also SSHD-873.
--
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-988) Replace net.ip artifact with Bouncycastle for EDDSA key support
[
https://issues.apache.org/jira/browse/SSHD-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097194#comment-17097194
]
Lyor Goldstein commented on SSHD-988:
-
There seem to be some internal limitations when compared to our current code:
{code:java|title=OpenSSHPrivateKeyUtil#parsePrivateKeyBlob}
String cipherName = kIn.readString();
if (!"none".equals(cipherName))// <<== what about bcrypt encrypted keys
{
throw new IllegalStateException("encrypted keys not supported");
}
int publicKeyCount = kIn.readU32();
if (publicKeyCount != 1) // <<== while it is unlikely to encounter multiple
keys the spec (and our code) support it
{
throw new IllegalStateException("multiple keys not supported");
}
String keyType = pkIn.readString();
if (!"ssh-ed25519".equals(keyType))// <<== the spec (and our code) allow
for RSA/DSS/EC keys as well
{
throw new IllegalStateException("can not parse private key of type " +
keyType);
}
{code}
> Replace net.ip artifact with Bouncycastle for EDDSA key support
> ---
>
> Key: SSHD-988
> URL: https://issues.apache.org/jira/browse/SSHD-988
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
>
> As of version 1.6 _Bouncycastle_ seems to support EDDSA keys. By replacing
> {{net,ip}} module with it we decrease the amount of external dependencies
> libraries.
> An important part of this effort would be to ensure that we preserve the
> ability to read (and perhaps write) keys from files with the current formats
> already supported (PEM, _Putty_, _OpenSSH_, etc.)
--
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-988) Replace net.ip artifact with Bouncycastle for EDDSA key support
[
https://issues.apache.org/jira/browse/SSHD-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097189#comment-17097189
]
Lyor Goldstein commented on SSHD-988:
-
{quote}
One notable difference is that net.i2p produces keys that return from
Key.getAlgorithm() "EdDSA", while the Bouncy Castle keys return "Ed25519" or
"Ed448", respectively.
{quote}
> Replace net.ip artifact with Bouncycastle for EDDSA key support
> ---
>
> Key: SSHD-988
> URL: https://issues.apache.org/jira/browse/SSHD-988
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Major
>
> As of version 1.6 _Bouncycastle_ seems to support EDDSA keys. By replacing
> {{net,ip}} module with it we decrease the amount of external dependencies
> libraries.
> An important part of this effort would be to ensure that we preserve the
> ability to read (and perhaps write) keys from files with the current formats
> already supported (PEM, _Putty_, _OpenSSH_, etc.)
--
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-988) Replace net.ip artifact with Bouncycastle for EDDSA key support
Lyor Goldstein created SSHD-988:
---
Summary: Replace net.ip artifact with Bouncycastle for EDDSA key
support
Key: SSHD-988
URL: https://issues.apache.org/jira/browse/SSHD-988
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 2.4.0
Reporter: Lyor Goldstein
Assignee: Lyor Goldstein
As of version 1.6 _Bouncycastle_ seems to support EDDSA keys. By replacing
{{net,ip}} module with it we decrease the amount of external dependencies
libraries.
An important part of this effort would be to ensure that we preserve the
ability to read (and perhaps write) keys from files with the current formats
already supported (PEM, _Putty_, _OpenSSH_, etc.)
--
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] [Work started] (SSHD-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-986 started by Lyor Goldstein.
---
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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] [Assigned] (SSHD-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-986:
---
Assignee: Lyor Goldstein
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17097444#comment-17097444
]
Lyor Goldstein commented on SSHD-986:
-
[~wolft] I believe I have solution (see
{{PKCS8PEMResourceKeyPairParser#extractKeyPairs}}, but for some reason when
comparing the recovered keys the {{Key#getEncoded()}} data is different - even
though all other parameters are the same. See
https://github.com/lgoldstein/mina-sshd/tree/SSHD-986 -
{{PKCS8PEMResourceKeyPairParserTest}}. I would appreciate your feedback (if you
have the time).
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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] [Reopened] (SSHD-709) All passwords should be stored as char[] instead of String and wiped after use
[ https://issues.apache.org/jira/browse/SSHD-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reopened SSHD-709: - > All passwords should be stored as char[] instead of String and wiped after use > -- > > Key: SSHD-709 > URL: https://issues.apache.org/jira/browse/SSHD-709 > Project: MINA SSHD > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Minor > -- 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-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-984.
-
Fix Version/s: 2.5.0
Resolution: Fixed
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Fix For: 2.5.0
>
> Attachments: sshd_key_writing.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098991#comment-17098991
]
Lyor Goldstein commented on SSHD-986:
-
{quote}
Are there different equivalent X.509 encodings for an EC key? (Named vs.
unnamed, or some such?)
{quote}
Might be, although as far as I understand they are supposed to use DER instead
of BER which is supposed to yield a deterministic result. Anyway, I removed the
encoding assertion since the keys +contents+ are tested, so if they are equal I
don't care how they are encoded (at least for the moment). Will publish a PR
soon.
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099130#comment-17099130
]
Lyor Goldstein commented on SSHD-986:
-
[~wolft] How about https://github.com/apache/mina-sshd/pull/129 ?
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-984) Utility method to export KeyPair in OpenSSH format
[
https://issues.apache.org/jira/browse/SSHD-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096255#comment-17096255
]
Lyor Goldstein commented on SSHD-984:
-
{quote}
I tried to extend that prototype for better PEM writing (including encryption),
but I think I don't quite understand how this should be done, or there are
things missing in sshd.
{quote}
I don't think you should try to extend an existing prototype but rather
invent/establish a new one. If I were to suggest something it would a
counterpoint to {{KeyPairResourceLoader}} - e.g., {{KeyPairResourceWriter}}.
{quote}
I don't see where and how I'd specify that I'd want to use
PBKDF2WithHMAC-SHA1AndAES256-CBC for a passphrase-protected key to be written
as a PKCS#8 PEM.
{quote}
Since you are establishing an entirely new hierarchy, do whatever seems right
at the moment - try to make it as generic as possible, but don't fret about it
too much. I am perfectly content with having some initial "rough" code that we
will polish as we encounter new requests to modify it. If you really want to
emphasize that it is experimental try defining it in the {{sshd-contrib}}
module - if it only "consumes" other code and not needed by the other modules.
> Utility method to export KeyPair in OpenSSH format
> --
>
> Key: SSHD-984
> URL: https://issues.apache.org/jira/browse/SSHD-984
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Attachments: sshd_key_writing.zip
>
>
> There are ongoing efforts in Gerrit Code Review and JGit projects to remove
> dependency on JSch library: [1], [2]. Instead, MINA SSSD should be used on
> both: client and server sides.
> One difficulty we are facing is the fact the MINA SSHD currently doesn't
> provide any means to export generated KeyPair in OpenSSH format.
> Thomas Wolf added recently the ability to read encrypted OpenSSH private keys
> in context of SSHD-708.
> With JSch this code would do the job:
> {code:java}
> public static com.jcraft.jsch.KeyPair genSshKey() throws JSchException {
> JSch jsch = new JSch();
> return KeyPair.genKeyPair(jsch, KeyPair.ECDSA, 256);
> }
> public static String publicKey(com.jcraft.jsch.KeyPair sshKey, @Nullable
> String comment)
> throws UnsupportedEncodingException {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> sshKey.writePublicKey(out, comment);
> return out.toString(US_ASCII.name()).trim();
> }
> public static byte[] privateKey(com.jcraft.jsch.KeyPair keyPair) {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> keyPair.writePrivateKey(out);
> return out.toByteArray();
> }
> {code}
> [1] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=540727]
> [2] [https://bugs.chromium.org/p/gerrit/issues/detail?id=12599]
--
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)
[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-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] [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-994) SCP commands redirect to SFTP subsystem
[
https://issues.apache.org/jira/browse/SSHD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108500#comment-17108500
]
Lyor Goldstein commented on SSHD-994:
-
Note: this will re-direct +all+ file API access for this session to SFTP. If
you want to be more fine-grained (e.g., redirect only specific virtual files) ,
then look into how to provide your own {{ScpFileOpener}} - specifically
{{resolveIncomingFilePath}} - where you can use a variation on the code I
suggested to choose which files to re-direct to the local file system and which
one to delegate SFTP - it is a bit trickier, but not too complex. If you do
want I can look over your code once you think you have implemented it.
> SCP commands redirect to SFTP subsystem
> ---
>
> Key: SSHD-994
> URL: https://issues.apache.org/jira/browse/SSHD-994
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.3.0
>Reporter: Sandeep
>Assignee: Lyor Goldstein
>Priority: Blocker
>
> Hi Team, I am working on one of the big project where SCP commands need to
> redirect to SFTP subsystem.
--
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-994) SCP commands redirect to SFTP subsystem
[ https://issues.apache.org/jira/browse/SSHD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-994. - Resolution: Implemented > SCP commands redirect to SFTP subsystem > --- > > Key: SSHD-994 > URL: https://issues.apache.org/jira/browse/SSHD-994 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.3.0 >Reporter: Sandeep >Assignee: Lyor Goldstein >Priority: Blocker > > Hi Team, I am working on one of the big project where SCP commands need to > redirect to SFTP subsystem. -- 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-992) Customizing sftp stat commands
[
https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108496#comment-17108496
]
Lyor Goldstein commented on SSHD-992:
-
{quote}
I think the small improvements can be made to SftpSubsystemFactory.Builder to
set custom SftpSubsystem
{quote}
I don't think it would help much - actually the implementation is
{{SubsystemFactory}} which is not SFTP specific. Furthermore it would make the
API "tied" to a specific implementation rather than a generic one. If this is
the way one wants to go it would be better to extend {{SftpSubsystemFactory}}
and override {{createSubsystem}} to return whatever subsystem one wants.
> Customizing sftp stat commands
> --
>
> Key: SSHD-992
> URL: https://issues.apache.org/jira/browse/SSHD-992
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Logan
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.5.0
>
>
> We use SSHD servers to support SFTP functionality that when user uploads a
> file, we internally create a file with a unique name and handle this upload.
> While this customization is working it does break some clients that issue
> stat command after upload. Is there a hook or customization that I can do to
> handle the stat commands ourselves instead of default handler? Have the same
> issues with getting attributes of the file too. Probably some hooks similar
> SftpFileSystemAccessor openFile?
--
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-994) SCP commands redirect to SFTP subsystem
[
https://issues.apache.org/jira/browse/SSHD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108497#comment-17108497
]
Lyor Goldstein commented on SSHD-994:
-
I believe I have simple solution for you:
{code:java}
SftpFileSystemProvider sfProvider=intialize...
FileSystemFactory fsFactory = new FileSystemFactory() {
@Override
public FileSystem createFileSystem(Session session) throws IOException {
if (..whatever condition...) {
return fsProvider.newFileSystem(...);
} else {
return NativeFileSystemFactory.INSTANCE.createFileSystem(session);
}
}
};
SshServer server = SshServer.setupDefaultServer();
server.setFileSystemFactory(fsFactory);
server.start();
{code}
> SCP commands redirect to SFTP subsystem
> ---
>
> Key: SSHD-994
> URL: https://issues.apache.org/jira/browse/SSHD-994
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.3.0
>Reporter: Sandeep
>Priority: Blocker
>
> Hi Team, I am working on one of the big project where SCP commands need to
> redirect to SFTP subsystem.
--
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] [Assigned] (SSHD-994) SCP commands redirect to SFTP subsystem
[ https://issues.apache.org/jira/browse/SSHD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-994: --- Assignee: Lyor Goldstein > SCP commands redirect to SFTP subsystem > --- > > Key: SSHD-994 > URL: https://issues.apache.org/jira/browse/SSHD-994 > Project: MINA SSHD > Issue Type: New Feature >Affects Versions: 2.3.0 >Reporter: Sandeep >Assignee: Lyor Goldstein >Priority: Blocker > > Hi Team, I am working on one of the big project where SCP commands need to > redirect to SFTP subsystem. -- 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=17107000#comment-17107000
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
On Gerrit side, I have been playing with the idea of setting
MAX_CONCURRENT_CHANNELS_PROP property to 1, to actually disable multiplexing
and avoid the issue for now. However, I could not find a how this property is
expected to be set
{quote}
Easy - call {{PropertyResolverUtils#updateProperty(...,
MAX_CONCURRENT_CHANNELS_PROP, 1)}} where first argument can be either the
client/server or the session. The difference is that if the property is set on
the client/server then it is +global+ (i.e. applies to all sessions) vs
+specific+ to the relevant session. See [Properties and inheritance
model|https://github.com/apache/mina-sshd/blob/master/docs/internals.md#properties-and-inheritance-model]
section of the documentation
> 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: 20m
> 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)
>
[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=17106989#comment-17106989
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
Hello! Could you make any progress on a fix?
{quote}
Sorry - have tried 2-3 new approaches but they did not pan out - I am waiting
for some inspiration.
> 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: 20m
> 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)
>
[jira] [Commented] (SSHD-994) SCP commands redirect to SFTP subsystem
[
https://issues.apache.org/jira/browse/SSHD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108880#comment-17108880
]
Lyor Goldstein commented on SSHD-994:
-
I have reviewed the code and have a few remarks/questions
* Why {{System.setProperty(IoServiceFactoryFactory.class.getName(),
MinaServiceFactoryFactory.class.getName());}} ? Is there any reason not to use
the NIO2 (which is the default) ?
* Why did you provide your own {{SSHDSftpSubsystemFactory}} ? From what I have
observed it seems identical to the default one.
* Finally, all the code does is initialize shell, SCP and SFTP - it does not
redirect SCP to SFTP as this issue implies
> SCP commands redirect to SFTP subsystem
> ---
>
> Key: SSHD-994
> URL: https://issues.apache.org/jira/browse/SSHD-994
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.3.0
>Reporter: Sandeep
>Assignee: Lyor Goldstein
>Priority: Blocker
> Attachments: server_scp_sftp_poc.zip
>
>
> Hi Team, I am working on one of the big project where SCP commands need to
> redirect to SFTP subsystem.
--
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-995) Custom user defined Exception ,message need to send
[
https://issues.apache.org/jira/browse/SSHD-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109089#comment-17109089
]
Lyor Goldstein commented on SSHD-995:
-
Simple - in the {{SftpSubsystemFactory}} register your own
{{SftpErrorStatusDataHandler}}.
I am happy to help but such questions are best solved by sending a message to
the dev@mina.apache,org mailing list rather than a JIRA issue.
> 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] [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=17110423#comment-17110423
]
Lyor Goldstein commented on SSHD-506:
-
Sounds very promising - when you think you have figured out the code please
publish a PR and I would be more than happy to review and eventually merge it.
One word of advice - since it is such a major/central feature please make sure
you add unit tests for it.
> 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] [Work started] (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 ] Work on SSHD-998 started by Lyor Goldstein. --- > 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 >Assignee: Lyor Goldstein >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] [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=17110425#comment-17110425
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
Even without multiplexing I get lots of errors, so I suspect there may be some
issue...
{quote}
If you think they originate from SSHD please add them to this issue - perhaps I
can shed some light on it.
> 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)
>
>
[jira] [Commented] (SSHD-791) Support the socks protocol
[
https://issues.apache.org/jira/browse/SSHD-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110398#comment-17110398
]
Lyor Goldstein commented on SSHD-791:
-
{quote}
Can any one share code snippet for the same, I also have exactly same
requirement.
{quote}
I second that - I would more than happy to integrate it as part of the next
deliverable
> Support the socks protocol
> --
>
> Key: SSHD-791
> URL: https://issues.apache.org/jira/browse/SSHD-791
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Zhenliang Su
>Priority: Minor
> Labels: socks
>
> There is a situation for me to use SshClient to connect remote server via a
> socks5 proxy server with Java code. I found the issue
> https://issues.apache.org/jira/browse/SSHD-656 , and I want to implement
> interface ClientProxyConnector to suit my issue, but I found it's impossible
> because socks5 protocol is not as simple as just send a packet, but need to
> send and receive multiple times.
--
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-998) respect SftpVersionSelector when establishing a new connection
[ https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110458#comment-17110458 ] Lyor Goldstein commented on SSHD-998: - [~ickzon] See https://github.com/apache/mina-sshd/pull/133 inspired by your patch. You can clone and test the code from https://github.com/lgoldstein/mina-sshd/tree/SSHD-998 > 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 >Assignee: Lyor Goldstein >Priority: Major > Labels: features, patch, performance > Attachments: patch.diff > > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Assigned] (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 ] Lyor Goldstein reassigned SSHD-998: --- Assignee: Lyor Goldstein > 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 >Assignee: Lyor Goldstein >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] [Commented] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110395#comment-17110395
]
Lyor Goldstein commented on SSHD-998:
-
{quote}
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
{quote}
Indeed - it is a violation of the protocol.
{quote}
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.
{quote}
Looks promising - I will certainly give it a look. You raise a valid point - we
should allow the client to choose the initial version being sent to the server.
I am not sure {{SftpVersionSelector}} is the solution in this case, but it is a
good candidate.
> 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] [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=17110387#comment-17110387
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
WARN org.apache.sshd.common.future.DefaultCloseFuture :
notifyListener(DefaultCloseFuture[id=Builder][value=true]) failed
(RuntimeSshException) to invoke
org.apache.sshd.common.util.closeable.SequentialCloseable$1@42b3beb5: null
Is this ok?
{quote}
Thanks for bringing it to my attention - I will look into it (though I do not
believe it is related to this issue).
> 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)
>
[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=17110390#comment-17110390
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
I am happy to report it seems to run much better indeed! Sorry for my earlier
report, and kudos for finding a fix! I have lots of errors (as expected since I
try to cause some timeouts while rekying...), I still need to verify the logs
to confirm nothing fishy there.
{quote}
Indeed, let's make sure we do not introduce "noise" that might mask out the
fix...
{quote}
I will also continue stressing this out, and let you know.
{quote}
Sounds promising - let me know.
> 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)
>
>
[jira] [Comment Edited] (SSHD-992) Customizing sftp stat commands
[
https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107835#comment-17107835
]
Lyor Goldstein edited comment on SSHD-992 at 5/15/20, 1:52 AM:
---
{quote}
we internally create a file with a unique name and handle this upload
{quote}
I am not sure I understand what this means and why this would prevent clients
to do {{stat}} or retrieve attributes
was (Author: lgoldstein):
{quote}
we internally create a file with a unique name and handle this upload
{quote}
I am not sure I understand what this means and why this would prevent clients
to do {{stat}} or retrieve attributes
{quote}
Probably some hooks similar SftpFileSystemAccessor openFile
{quote}
I will look into it...
> Customizing sftp stat commands
> --
>
> Key: SSHD-992
> URL: https://issues.apache.org/jira/browse/SSHD-992
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
>
> We use SSHD servers to support SFTP functionality that when user uploads a
> file, we internally create a file with a unique name and handle this upload.
> While this customization is working it does break some clients that issue
> stat command after upload. Is there a hook or customization that I can do to
> handle the stat commands ourselves instead of default handler? Have the same
> issues with getting attributes of the file too. Probably some hooks similar
> SftpFileSystemAccessor openFile?
--
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] [Work started] (SSHD-992) Customizing sftp stat commands
[ https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-992 started by Lyor Goldstein. --- > Customizing sftp stat commands > -- > > Key: SSHD-992 > URL: https://issues.apache.org/jira/browse/SSHD-992 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Logan >Assignee: Lyor Goldstein >Priority: Major > > We use SSHD servers to support SFTP functionality that when user uploads a > file, we internally create a file with a unique name and handle this upload. > While this customization is working it does break some clients that issue > stat command after upload. Is there a hook or customization that I can do to > handle the stat commands ourselves instead of default handler? Have the same > issues with getting attributes of the file too. Probably some hooks similar > SftpFileSystemAccessor openFile? -- 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-992) Customizing sftp stat commands
[
https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-992.
-
Fix Version/s: 2.5.0
Resolution: Fixed
Moved most of the relevant local files manipulation to the
{{SftpFileSystemAccessor}}
> Customizing sftp stat commands
> --
>
> Key: SSHD-992
> URL: https://issues.apache.org/jira/browse/SSHD-992
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Logan
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.5.0
>
>
> We use SSHD servers to support SFTP functionality that when user uploads a
> file, we internally create a file with a unique name and handle this upload.
> While this customization is working it does break some clients that issue
> stat command after upload. Is there a hook or customization that I can do to
> handle the stat commands ourselves instead of default handler? Have the same
> issues with getting attributes of the file too. Probably some hooks similar
> SftpFileSystemAccessor openFile?
--
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=17107827#comment-17107827
]
Lyor Goldstein commented on SSHD-966:
-
Looks very similar indeed...
> 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: 20m
> 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)
> "sshd-SshServer[df5f657]-nio2-thread-3" daemon prio=5 BLOCKED
>
>
[jira] [Commented] (SSHD-992) Customizing sftp stat commands
[
https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107835#comment-17107835
]
Lyor Goldstein commented on SSHD-992:
-
{quote}
we internally create a file with a unique name and handle this upload
{quote}
I am not sure I understand what this means and why this would prevent clients
to do {{stat}} or retrieve attributes
{quote}
Probably some hooks similar SftpFileSystemAccessor openFile
{quote}
I will look into it...
> Customizing sftp stat commands
> --
>
> Key: SSHD-992
> URL: https://issues.apache.org/jira/browse/SSHD-992
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
>
> We use SSHD servers to support SFTP functionality that when user uploads a
> file, we internally create a file with a unique name and handle this upload.
> While this customization is working it does break some clients that issue
> stat command after upload. Is there a hook or customization that I can do to
> handle the stat commands ourselves instead of default handler? Have the same
> issues with getting attributes of the file too. Probably some hooks similar
> SftpFileSystemAccessor openFile?
--
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] [Assigned] (SSHD-992) Customizing sftp stat commands
[ https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-992: --- Assignee: Lyor Goldstein > Customizing sftp stat commands > -- > > Key: SSHD-992 > URL: https://issues.apache.org/jira/browse/SSHD-992 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Logan >Assignee: Lyor Goldstein >Priority: Major > > We use SSHD servers to support SFTP functionality that when user uploads a > file, we internally create a file with a unique name and handle this upload. > While this customization is working it does break some clients that issue > stat command after upload. Is there a hook or customization that I can do to > handle the stat commands ourselves instead of default handler? Have the same > issues with getting attributes of the file too. Probably some hooks similar > SftpFileSystemAccessor openFile? -- 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-992) Customizing sftp stat commands
[
https://issues.apache.org/jira/browse/SSHD-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107841#comment-17107841
]
Lyor Goldstein commented on SSHD-992:
-
{quote}
Probably some hooks similar SftpFileSystemAccessor openFile
{quote}
I am not clear as to how these hooks would behave and where to hook them in the
code. However, for the time being you could extend {{SftpSubsystem}} class and
override {{protected Map doStat(int id, String path, int
flags)}} (inherited from {{AbstractSftpSubsystemHelper}}) - same applies to
{{getAttributes}} method. Then you can use your class:
{code:java}
SshServer sshd = ;
sshd.setSubsystemFactories(Collections.singletonList(new SftpSubsystemFactory()
{
@Override
public Command createSubsystem(ChannelSession channel) throws
IOException {
return new MySuperDuperSftpSubsystem(
resolveExecutorService(),
getUnsupportedAttributePolicy(), getFileSystemAccessor(),
getErrorStatusDataHandler());
}
}));
{code}
> Customizing sftp stat commands
> --
>
> Key: SSHD-992
> URL: https://issues.apache.org/jira/browse/SSHD-992
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.1.0
>Reporter: Logan
>Priority: Major
>
> We use SSHD servers to support SFTP functionality that when user uploads a
> file, we internally create a file with a unique name and handle this upload.
> While this customization is working it does break some clients that issue
> stat command after upload. Is there a hook or customization that I can do to
> handle the stat commands ourselves instead of default handler? Have the same
> issues with getting attributes of the file too. Probably some hooks similar
> SftpFileSystemAccessor openFile?
--
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=17107961#comment-17107961
]
Lyor Goldstein commented on SSHD-966:
-
{quote}
Can you comment on performance implication for disabling multiplexing? Also can
you see why the same problem would not happen in MINA backend? Or is that the
problem reporter was just lucky and the problem could also happen in MINA
backend and we should rather disable the multiplexing on both backends?
{quote}
Not really - hard to tell. I do have another idea that seems hopeful (like
those before it...) - cross your fingers...
> 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: 20m
> 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)
>
[jira] [Commented] (SSHD-993) an additional connection is created when connect to a sshd server
[
https://issues.apache.org/jira/browse/SSHD-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108054#comment-17108054
]
Lyor Goldstein commented on SSHD-993:
-
I don't think this has anything to do with the server. The server is +passive+
- i.e., it does not initiate connection - only clients do. Therefore I am not
sure how it is the "fault" of the MINA SSHD server. I believe you can confirm
that if you run Wireshark or TCPDUMP to see the connection attempts.
> an additional connection is created when connect to a sshd server
> -
>
> Key: SSHD-993
> URL: https://issues.apache.org/jira/browse/SSHD-993
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Shengdi
>Priority: Minor
>
> I used
> SshServer sshd = SshServer.setUpDefaultServer(); to start an sshd server.
>
> When I connect to server with several terminals, and then I keep connect with
> other terminals, then I can probably find the additional ones. This is
> randomly, and most happens after multiple connecting simultaneously or very
> close, then other connect will cause additional connection
> Here is an example,
> I connect with 5 terminals very closely, i found 5 connections with netstat,
> this is correct
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> But then connect one more time, then i found two connection established this
> time,
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> {color:#ff}TCP 127.0.0.1:63890 127.0.0.1:12399 ESTABLISHED 35316{color}
> {color:#ff} TCP 127.0.0.1:63891 127.0.0.1:12399 ESTABLISHED 22568{color}
>
> Does anyone have any idea about this? how the additional connection caused?
> Great Thanks
>
> Cheers
> Shengdi
>
>
> ==
> Following is my code example
> ==
> public class SSHServer {
> private SshServer sshd;
> public SSHServer() {
> sshd = SshServer.setUpDefaultServer();
> }
> public void start() throws IOException {
> sshd.setHost("127.0.0.1");
> sshd.setPort(12399);
> sshd.setKeyPairProvider(new MyKeyProvider());
> sshd.setShellFactory(getShellFactory());
> sshd.setPublickeyAuthenticator(new MyAuthenticator());
> sshd.getProperties().put(SshServer.IDLE_TIMEOUT, String.valueOf(30));
> // Start SSH server
> sshd.start();
> }
> private Factory getShellFactory() {
> return new Factory() {
> @Override
> public Command create() {
> return new MyShell();
> }
> };
> }
> }
>
--
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-993) an additional connection is created when connect to a sshd server
[
https://issues.apache.org/jira/browse/SSHD-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17108067#comment-17108067
]
Lyor Goldstein commented on SSHD-993:
-
In any case, I see you are using version 2.1.0 - I recommend upgrading to 2.4.0
(I don't think it has anything to do with this issue, but who knows...)
> an additional connection is created when connect to a sshd server
> -
>
> Key: SSHD-993
> URL: https://issues.apache.org/jira/browse/SSHD-993
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Shengdi
>Priority: Minor
>
> I used
> SshServer sshd = SshServer.setUpDefaultServer(); to start an sshd server.
>
> When I connect to server with several terminals, and then I keep connect with
> other terminals, then I can probably find the additional ones. This is
> randomly, and most happens after multiple connecting simultaneously or very
> close, then other connect will cause additional connection
> Here is an example,
> I connect with 5 terminals very closely, i found 5 connections with netstat,
> this is correct
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> But then connect one more time, then i found two connection established this
> time,
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> {color:#ff}TCP 127.0.0.1:63890 127.0.0.1:12399 ESTABLISHED 35316{color}
> {color:#ff} TCP 127.0.0.1:63891 127.0.0.1:12399 ESTABLISHED 22568{color}
>
> Does anyone have any idea about this? how the additional connection caused?
> Great Thanks
>
> Cheers
> Shengdi
>
>
> ==
> Following is my code example
> ==
>
> {code:java}
> public class SSHServer {
> private SshServer sshd;
> public SSHServer() {
> sshd = SshServer.setUpDefaultServer();
> }
> public void start() throws IOException {
> sshd.setHost("127.0.0.1");
> sshd.setPort(12399);
> sshd.setKeyPairProvider(new MyKeyProvider());
> sshd.setShellFactory(getShellFactory());
> sshd.setPublickeyAuthenticator(new MyAuthenticator());
> sshd.getProperties().put(SshServer.IDLE_TIMEOUT,
> String.valueOf(30));
> // Start SSH server
> sshd.start();
> }
>private Factory getShellFactory() {
> return new Factory() {
> @Override
> public Command create() {
> return new MyShell();
> }
> };
> }
> }
>
> {code}
>
--
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=17108089#comment-17108089
]
Lyor Goldstein commented on SSHD-966:
-
[~davido2] I published https://github.com/apache/mina-sshd/pull/131 that IMO
seems to fix this issue. I would appreciate some review on it. It's not very
elegant but it does have several advantages:
* The cooperating classes use a single lock instead of 2
* Even if there is a deadlock it will eventually time out after at most ~2 min.
so at least the code won't hang
If you want to test the code you can clone it at
https://github.com/lgoldstein/mina-sshd/tree/SSHD-966
Let me know...
Thanks.
> 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)
>
>
[jira] [Updated] (SSHD-993) an additional connection is created when connect to a sshd server
[
https://issues.apache.org/jira/browse/SSHD-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-993:
Priority: Minor (was: Major)
> an additional connection is created when connect to a sshd server
> -
>
> Key: SSHD-993
> URL: https://issues.apache.org/jira/browse/SSHD-993
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.0
>Reporter: Shengdi
>Priority: Minor
>
> I used
> SshServer sshd = SshServer.setUpDefaultServer(); to start an sshd server.
>
> When I connect to server with several terminals, and then I keep connect with
> other terminals, then I can probably find the additional ones. This is
> randomly, and most happens after multiple connecting simultaneously or very
> close, then other connect will cause additional connection
> Here is an example,
> I connect with 5 terminals very closely, i found 5 connections with netstat,
> this is correct
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> But then connect one more time, then i found two connection established this
> time,
> TCP 127.0.0.1:63862 127.0.0.1:12399 ESTABLISHED 4
> TCP 127.0.0.1:63864 127.0.0.1:12399 ESTABLISHED 42764
> TCP 127.0.0.1:63868 127.0.0.1:12399 ESTABLISHED 47036
> TCP 127.0.0.1:63874 127.0.0.1:12399 ESTABLISHED 42516
> TCP 127.0.0.1:63879 127.0.0.1:12399 ESTABLISHED 41704
> {color:#ff}TCP 127.0.0.1:63890 127.0.0.1:12399 ESTABLISHED 35316{color}
> {color:#ff} TCP 127.0.0.1:63891 127.0.0.1:12399 ESTABLISHED 22568{color}
>
> Does anyone have any idea about this? how the additional connection caused?
> Great Thanks
>
> Cheers
> Shengdi
>
>
> ==
> Following is my code example
> ==
> public class SSHServer {
> private SshServer sshd;
> public SSHServer() {
> sshd = SshServer.setUpDefaultServer();
> }
> public void start() throws IOException {
> sshd.setHost("127.0.0.1");
> sshd.setPort(12399);
> sshd.setKeyPairProvider(new MyKeyProvider());
> sshd.setShellFactory(getShellFactory());
> sshd.setPublickeyAuthenticator(new MyAuthenticator());
> sshd.getProperties().put(SshServer.IDLE_TIMEOUT, String.valueOf(30));
> // Start SSH server
> sshd.start();
> }
> private Factory getShellFactory() {
> return new Factory() {
> @Override
> public Command create() {
> return new MyShell();
> }
> };
> }
> }
>
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101699#comment-17101699
]
Lyor Goldstein edited comment on SSHD-986 at 5/7/20, 1:53 PM:
--
{quote}
That's the "read public key from encoded private key data" solution
{quote}
That's why I opened SSHD-989
{quote}
Looks OK.
{quote}
I'll add a few more tests and then merge it in soon.
was (Author: lgoldstein):
I'll add a few more tests and then merge it in soon.
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101699#comment-17101699
]
Lyor Goldstein commented on SSHD-986:
-
I'll add a few more tests and then merge it in soon.
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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-989) Read correctly ECDSA key pair from PKCS8 encoded data
Lyor Goldstein created SSHD-989: --- Summary: Read correctly ECDSA key pair from PKCS8 encoded data Key: SSHD-989 URL: https://issues.apache.org/jira/browse/SSHD-989 Project: MINA SSHD Issue Type: Sub-task Affects Versions: 2.4.0 Reporter: Lyor Goldstein Assignee: Lyor Goldstein -- 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] [Work started] (SSHD-989) Read correctly ECDSA key pair from PKCS8 encoded data
[ https://issues.apache.org/jira/browse/SSHD-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-989 started by Lyor Goldstein. --- > Read correctly ECDSA key pair from PKCS8 encoded data > - > > Key: SSHD-989 > URL: https://issues.apache.org/jira/browse/SSHD-989 > Project: MINA SSHD > Issue Type: Sub-task >Affects Versions: 2.4.0 >Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Major > -- 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] [Work stopped] (SSHD-986) Implement ECDSA public key recovery
[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-986 stopped by Lyor Goldstein.
---
> Implement ECDSA public key recovery
> ---
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
>Affects Versions: 2.4.0
>Reporter: Thomas Wolf
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: ECRecoverTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
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=17062666#comment-17062666
]
Lyor Goldstein commented on SSHD-966:
-
I have tried several workarounds - but none successful. This is a tough one -
still looking Basically, the problem is that we need to flush all the
pending messages that were accumulated while KEX was in progress and then mark
KEX as DONE. However, we must do this while preventing other packets from being
sent until flush is complete. I have thought about using a dedicated +thread+
that waits on a pending outgoing queue of messages - it would solve this issue,
but raise others - e.g., the need to return an {{IOWriteFuture}} from
{{writePacket}} (possible, but adds non-trivial complexity).
any ideas ?
> 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: 10m
> 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)
>
>
[jira] [Updated] (SSHD-990) Add support for reading encrypted PKCS8 PEM keys
[
https://issues.apache.org/jira/browse/SSHD-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-990:
Description:
{quote}
The encrypted form of a PEM encode PKCS#8 files uses the following headers and
footers:
-BEGIN ENCRYPTED PRIVATE KEY-
-END ENCRYPTED PRIVATE KEY-
{quote}
> Add support for reading encrypted PKCS8 PEM keys
>
>
> Key: SSHD-990
> URL: https://issues.apache.org/jira/browse/SSHD-990
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Lyor Goldstein
>Priority: Major
>
> {quote}
> The encrypted form of a PEM encode PKCS#8 files uses the following headers
> and footers:
> -BEGIN ENCRYPTED PRIVATE KEY-
> -END ENCRYPTED PRIVATE KEY-
> {quote}
--
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-990) Add support for reading encrypted PKCS8 PEM keys
Lyor Goldstein created SSHD-990: --- Summary: Add support for reading encrypted PKCS8 PEM keys Key: SSHD-990 URL: https://issues.apache.org/jira/browse/SSHD-990 Project: MINA SSHD Issue Type: Improvement Affects Versions: 2.4.0 Reporter: Lyor Goldstein -- 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-707) Add support for writing OpenSSH ed25519 private keys to file
[ https://issues.apache.org/jira/browse/SSHD-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-707. - Fix Version/s: 2.5.0 Resolution: Fixed > Add support for writing OpenSSH ed25519 private keys to file > > > Key: SSHD-707 > URL: https://issues.apache.org/jira/browse/SSHD-707 > Project: MINA SSHD > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Lyor Goldstein >Priority: Minor > Fix For: 2.5.0 > > > The current code knows how to read private keys from _OpenSSH_ formatted > private key files, and also contains some hooks for writing the data, > although more work is required - especially on generating the 64-octets hash > value. -- 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-991) Add support for reading PKCS8 public keys
Lyor Goldstein created SSHD-991:
---
Summary: Add support for reading PKCS8 public keys
Key: SSHD-991
URL: https://issues.apache.org/jira/browse/SSHD-991
Project: MINA SSHD
Issue Type: Improvement
Reporter: Lyor Goldstein
{quote}
-BEGIN PUBLIC KEY-
MEkwEwYHKoZIzj0CAQYIKoZIzj0DAQMDMgAE+Y+qPqI3geo2hQH8eK7Rn+YWG09T
ejZ5QFoj9fmxFrUyYhFap6XmTdJtEi8myBmW
-END PUBLIC KEY-
{quote}
--
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:
Issue Type: Bug (was: New Feature)
> 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: Bug
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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: Major (was: Minor)
> 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: Bug
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Work started] (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
]
Work on SSHD-997 started by Lyor Goldstein.
---
> 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: Bug
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Assigned] (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 reassigned SSHD-997:
---
Assignee: Lyor Goldstein
> 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: Bug
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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=17112474#comment-17112474
]
Lyor Goldstein commented on SSHD-997:
-
Thanks for the diagnosis and pull request - I have reviewed it and have no
comments. I will put it through the build process and then merge it in if there
are no problems.
> 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: Bug
>Affects Versions: 2.4.0
>Reporter: David Ostrovsky
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-998) respect SftpVersionSelector when establishing a new connection
[
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111276#comment-17111276
]
Lyor Goldstein commented on SSHD-998:
-
{quote}Your changes will break backward compatibility though, but surely you
are aware of that.
{quote}
Yes but:
* It's not something major that would confuse programmers who upgrade to it
* The next release (2.5) also breaks other backward compatibility (hence
2.+*5*+)
> 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
>Assignee: Lyor Goldstein
>Priority: Major
> Labels: features, patch, performance
> Attachments: patch.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111278#comment-17111278
]
Lyor Goldstein commented on SSHD-998:
-
{quote}
I tested your code and can confirm it works as expected.
{quote}
Thanks will merge...
> 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
>Assignee: Lyor Goldstein
>Priority: Major
> Labels: features, patch, performance
> Attachments: patch.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Resolved] (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 ] Lyor Goldstein resolved SSHD-998. - Fix Version/s: 2.5.0 Resolution: Fixed > 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 >Assignee: Lyor Goldstein >Priority: Major > Labels: features, patch, performance > Fix For: 2.5.0 > > Attachments: patch.diff > > Time Spent: 20m > Remaining Estimate: 0h > > 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] [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=17111280#comment-17111280
]
Lyor Goldstein commented on SSHD-966:
-
I'll see what I can do
> 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)
> "sshd-SshServer[df5f657]-nio2-thread-3" daemon prio=5 BLOCKED
>
>
[jira] [Comment Edited] (SSHD-1000) Limit Max unique user session.
[
https://issues.apache.org/jira/browse/SSHD-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113422#comment-17113422
]
Lyor Goldstein edited comment on SSHD-1000 at 5/22/20, 4:37 AM:
Sounds reasonable - though not entirely part of the SSHD standard. Before we go
ahead and implement it in the framework can you provide some use case where
this would be useful ? Why would someone want to limit the number of unique
usernames rather than number of sessions. The limit on the sessions is in place
in order to protect the server from consuming too many resources. What would
limiting the number of unique users help prevent ?
Anyway, you can implement it right now - simply register a {{SessionListener}},
wait to be notified of new user authentication successful. Track the
(successful) username then throw an exception if it exceeds some convenient
number.
was (Author: lgoldstein):
Sounds reasonable - though not entirely part of the SSHD standard. Before we go
ahead and implement it in the framework can you provide some use case where
this would be useful ? Why would someone want to limit the number of unique
usernames rather than number of sessions. The limit on the sessions is in place
in order to protect the server from consuming too many resources. What would
limiting the number of unique users help prevent ?
Anyway, you can implement it right now - simply register a {{SessionListener}},
wait to be notified of new user authentication successful. Track the username
successful then throw an exception if it exceeds some convenient number.
> Limit Max unique user session.
> --
>
> Key: SSHD-1000
> URL: https://issues.apache.org/jira/browse/SSHD-1000
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Sandeep
>Assignee: Lyor Goldstein
>Priority: Major
>
> Hi Team we have MAX_CONCURRENT_SESSIONS property but I want limit Max
> unique user login.
> e.g let say MAX_USER_LOGINS =10 then our server can allow max 10 unique user
> logins only.
> Code :
> I have checked library code and created some sudo code using old method for
> max_concurrent_sessions as follows,
> Note * it does not have unique user check we can add it.
>
> {code:java}
> // code placeholder
> public int getActiveSessionUserCount() {
> IoSession networkSession = getIoSession();
> IoService service = networkSession.getService();
> Map sessionsMap = service.getManagedSessions();
> if (GenericUtils.isEmpty(sessionsMap)) {
> return 0;
> }int totalCount = 0;
> for (IoSession is : sessionsMap.values()) {
> ServerSession session = (ServerSession) getSession(is, true);
> if (session == null) {
> continue;
> }String sessionUser = session.getUsername();
> if (!GenericUtils.isEmpty(sessionUser)) {
> totalCount++;
> }
> }
> return totalCount;
> }
> {code}
>
--
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
