[jira] [Updated] (SSHD-1132) Add support for SFTP "filename-charset" extension
[ https://issues.apache.org/jira/browse/SSHD-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1132: - Labels: SFTP sftp (was: ) > Add support for SFTP "filename-charset" extension > - > > Key: SSHD-1132 > URL: https://issues.apache.org/jira/browse/SSHD-1132 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Priority: Minor > Labels: SFTP, sftp > > See https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-16 -- 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-1109) Replace log4j with logback as the slf4j logger implementation for tests
[
https://issues.apache.org/jira/browse/SSHD-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291078#comment-17291078
]
Lyor Goldstein commented on SSHD-1109:
--
Please post you question to dev@mina.apache.org - we have nothing to hide... :)
> Replace log4j with logback as the slf4j logger implementation for tests
> ---
>
> Key: SSHD-1109
> URL: https://issues.apache.org/jira/browse/SSHD-1109
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.7.0
>
>
> See if can use a single common file in the {{sshd-common}} module
--
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-1085) channel.waitFor() get stuck when run reboot command
[
https://issues.apache.org/jira/browse/SSHD-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291079#comment-17291079
]
Lyor Goldstein commented on SSHD-1085:
--
I am not aware of any mailing list...
> channel.waitFor() get stuck when run reboot command
> ---
>
> Key: SSHD-1085
> URL: https://issues.apache.org/jira/browse/SSHD-1085
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: linux
>Reporter: min yun law
>Assignee: Lyor Goldstein
>Priority: Major
>
> Trying to run linux command "reboot" by mina sshd to remote node, the node is
> in reboot, but the ClientChannel object still keep open, not in closed
> status, Here is the logic code in my project:
>
> {code:java}
> String command = "reboot";
> ChannelExec channel = clientSession.createExecChannel(command);
> if(!channel.isClosed())
> {
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ByteArrayOutputStream err = new ByteArrayOutputStream(); channel.setOut(out);
> channel.setErr(err);
> channel.open().await(); //this passed
> //follow call will cause stuck
> Collection waitMask =
> channel.waitFor(REMOTE_COMMAND_WAIT_EVENTS, 0L);
> String outputStr = new String(out.toByteArray(), StandardCharsets.UTF_8);
> //some case this will throw runtime exception
> int exitStatus = channel.getExitStatus();
> }
>
> {code}
>
> So why the ChannelExec cannot get the correct channel status when remote node
> is rebooting?
>
>
>
--
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-1125) Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1125:
Assignee: Lyor Goldstein
> Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
> -
>
> Key: SSHD-1125
> URL: https://issues.apache.org/jira/browse/SSHD-1125
> Project: MINA SSHD
> Issue Type: Bug
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: memory
>
> Use an upper bound to the data pending in the {{BufferedIoOutputStream}}. The
> max data could be set to the max window size. Blocking until there is enough
> room should allow the client to read the data.
--
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-1125) Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1125 started by Lyor Goldstein.
> Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
> -
>
> Key: SSHD-1125
> URL: https://issues.apache.org/jira/browse/SSHD-1125
> Project: MINA SSHD
> Issue Type: Bug
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: memory
>
> Use an upper bound to the data pending in the {{BufferedIoOutputStream}}. The
> max data could be set to the max window size. Blocking until there is enough
> room should allow the client to read the data.
--
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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291169#comment-17291169
]
Lyor Goldstein commented on SSHD-1131:
--
{quote}
Is there anything we can achieve same with Mina as well as associated with the
SsshServer to make things easy?
{quote}
Note that this also ties in with [~twolf]-s question about the used SFTP
version. You need at least version 6 in order to use the "filename-charset"
extension (see SSHD-1132). Even if we do implement it, if the client use a
version less than 6 then you have no recourse but to derive your own
{{SftpSubsystem}} implementation and "skew" it somehow to do what you need.
{quote}
the commercial legacy server team provided us a solution
{quote}
We are not a commercial server team and do not posses the same resources and
manpower... :). I would encourage you to derive your own {{SftpSubsystem}}
implementation and contribute its code to the project, otherwise I don't see
this being addressed by us.
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291170#comment-17291170
]
Lyor Goldstein commented on SSHD-1131:
--
{quote}
Thomas Wolf - Sorry for asking it where can I find it?
I was asking about the SFTP protocol version. Version 3, 4, 5, 6, ...?
{quote}
The TECTIA client should have some way to tell you which version it is using -
in SFTP the +client+ chooses the version out of the ones reported as being
supported by the server.
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291185#comment-17291185
]
Lyor Goldstein commented on SSHD-1131:
--
{quote}
Meanwhile, I will be waiting for the feature for SSHD-1132 greedily
{quote}
Like I said - it will not help with version 3 so I don't think it will fix this
issue for you ... :(
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1125) Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291188#comment-17291188
]
Lyor Goldstein commented on SSHD-1125:
--
{noformat:title=After fix}
22:08:53.994 | ERROR | bsystem-thread-1 | o.a.s.s.s.SftpSubsystem |
org.apache.sshd.common.util.logging.LoggingUtils 685 |
run(ServerSessionImpl[testReadRequestsOutOfMemory@/127.0.0.1:50710])
SshChannelBufferedOutputException caught in SFTP subsystem: Max. pending write
timeout expired after 2096412 bytes
{noformat}
> Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
> -
>
> Key: SSHD-1125
> URL: https://issues.apache.org/jira/browse/SSHD-1125
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: memory
>
> Use an upper bound to the data pending in the {{BufferedIoOutputStream}}. The
> max data could be set to the max window size. Blocking until there is enough
> room should allow the client to read the data.
--
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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291192#comment-17291192
]
Lyor Goldstein commented on SSHD-1131:
--
I fully agree with everything [~twolf] said
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1131.
--
Resolution: Information Provided
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: New Feature
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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] [Updated] (SSHD-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1131:
-
Issue Type: Wish (was: New Feature)
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: Wish
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1125) Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291219#comment-17291219
]
Lyor Goldstein commented on SSHD-1125:
--
[~twolf], [~gnodet] I would appreciate it if you could take a look at
https://github.com/apache/mina-sshd/pull/181 and provide your feedback on it...
Thx.
> Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
> -
>
> Key: SSHD-1125
> URL: https://issues.apache.org/jira/browse/SSHD-1125
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: memory
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Use an upper bound to the data pending in the {{BufferedIoOutputStream}}. The
> max data could be set to the max window size. Blocking until there is enough
> room should allow the client to read the data.
--
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-1132) Add support for SFTP "filename-charset" extension
[ https://issues.apache.org/jira/browse/SSHD-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1132: Assignee: Lyor Goldstein > Add support for SFTP "filename-charset" extension > - > > Key: SSHD-1132 > URL: https://issues.apache.org/jira/browse/SSHD-1132 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Minor > Labels: SFTP, sftp > > See https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-16 -- 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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291382#comment-17291382
]
Lyor Goldstein commented on SSHD-1131:
--
Even so, it will require implementing your own {{SftpSubsystem}} derived class
since the conversion from the UNICODE file name that is provided in the Java
string to whatever charset one might require is not something we can do in a
generic way - especially the error handling part in case the file name is +not+
convertible to the target charset. This is why UTF-8 is so crucial since
UNICODE can always be converted to UTF-8 safely.
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: Wish
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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-1131) Filenames containing Norwegian Characters not allowed over SFTP in Tectia client
[
https://issues.apache.org/jira/browse/SSHD-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291387#comment-17291387
]
Lyor Goldstein commented on SSHD-1131:
--
No, this requires an entire different code to be patched - I will open an issue
for it as well, but don't hold your breath - it is not clear when we might get
to either issue...
> Filenames containing Norwegian Characters not allowed over SFTP in Tectia
> client
>
>
> Key: SSHD-1131
> URL: https://issues.apache.org/jira/browse/SSHD-1131
> Project: MINA SSHD
> Issue Type: Wish
>Reporter: Susmit Sarkar
>Priority: Major
> Labels: mina, sshd
> Attachments: image-2021-02-24-15-38-39-337.png
>
>
> Hi,
> Filenames containing Norwegian, Spanish, French, and German Characters not
> allowed over SFTP in Tectia client, names are getting messed up
> How can I override the decoding charset in *SshServer* :
> DecodingCharset is present for SftpClient:
> client.setNameDecodingCharset(Charset.forName("ISO-8859-8"));
> by default it uses UTF-8
> The SftpClient exposes a get/setNameDecodingCharset method which enables the
> user to modify the charset - even while the SFTP session is in progress
> After the file is uploaded the Norwegian characters in the filename are
> replaced with non-readable characters.
> Can we configure the SshServer to override the decoding charset from the
> default UTF-8? Is there any API to set the SFTP CharsetEncoding (Set the
> default encoding for filenames in SFTP sessions)
> !image-2021-02-24-15-38-39-337.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] [Created] (SSHD-1133) Provide non-UTF8 charset encoding capability to SCP implementation
Lyor Goldstein created SSHD-1133: Summary: Provide non-UTF8 charset encoding capability to SCP implementation Key: SSHD-1133 URL: https://issues.apache.org/jira/browse/SSHD-1133 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein Some non-standard clients/servers might employ non-UTF8 encoding - provide some way to encode/decode these names on both sides of the SCP protocol -- 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-1133) Provide non-UTF8 charset encoding capability to SCP implementation
[
https://issues.apache.org/jira/browse/SSHD-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291388#comment-17291388
]
Lyor Goldstein commented on SSHD-1133:
--
See {{ScpIoUtils#readLine/writeLine}} - seems that adding an extra {{Charset}}
to these methods should do the trick.
> Provide non-UTF8 charset encoding capability to SCP implementation
> --
>
> Key: SSHD-1133
> URL: https://issues.apache.org/jira/browse/SSHD-1133
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Minor
>
> Some non-standard clients/servers might employ non-UTF8 encoding - provide
> some way to encode/decode these names on both sides of the SCP protocol
--
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-1133) Provide non-UTF8 charset encoding capability to SCP implementation
[
https://issues.apache.org/jira/browse/SSHD-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291388#comment-17291388
]
Lyor Goldstein edited comment on SSHD-1133 at 2/26/21, 5:04 AM:
See {{ScpIoUtils#readLine/writeLine}} - seems that adding an extra {{Charset}}
to these methods should do the trick. Need to propagate
{{ScpModuleProperties#NAME_ENCODING_CHARSET}} to it.
was (Author: lgoldstein):
See {{ScpIoUtils#readLine/writeLine}} - seems that adding an extra {{Charset}}
to these methods should do the trick.
> Provide non-UTF8 charset encoding capability to SCP implementation
> --
>
> Key: SSHD-1133
> URL: https://issues.apache.org/jira/browse/SSHD-1133
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Minor
>
> Some non-standard clients/servers might employ non-UTF8 encoding - provide
> some way to encode/decode these names on both sides of the SCP protocol
--
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-1133) Provide non-UTF8 charset encoding capability to SCP implementation
[ https://issues.apache.org/jira/browse/SSHD-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1133: Assignee: Lyor Goldstein > Provide non-UTF8 charset encoding capability to SCP implementation > -- > > Key: SSHD-1133 > URL: https://issues.apache.org/jira/browse/SSHD-1133 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein > Assignee: Lyor Goldstein >Priority: Minor > > Some non-standard clients/servers might employ non-UTF8 encoding - provide > some way to encode/decode these names on both sides of the SCP protocol -- 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-1133) Provide non-UTF8 charset encoding capability to SCP implementation
[ https://issues.apache.org/jira/browse/SSHD-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1133 started by Lyor Goldstein. > Provide non-UTF8 charset encoding capability to SCP implementation > -- > > Key: SSHD-1133 > URL: https://issues.apache.org/jira/browse/SSHD-1133 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein > Assignee: Lyor Goldstein >Priority: Minor > > Some non-standard clients/servers might employ non-UTF8 encoding - provide > some way to encode/decode these names on both sides of the SCP protocol -- 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-1132) Add support for SFTP "filename-charset" extension
[
https://issues.apache.org/jira/browse/SSHD-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291516#comment-17291516
]
Lyor Goldstein commented on SSHD-1132:
--
[~twolf] These a very good points - my intention with this issue was indeed
+not+ to actually implement the full support for this extension. Rather provide
client-side support (which is easy) and modify {{SftpSubsystem}} in such a way
as to facilitate extending it so that users who do feel "adventurous" and
willing to undertake this task will find it easier to implement this in
whichever way they wish to interpret the extension behavior. I have no
intention to provide an implementation of our own not only because of the
points you have raised but also because there are many unanswered problems
(such as encoding/decoding issues at either client or server) that I have no
wish to engage...
{quote}the wise do not get into trouble that the smart know how to get out of
{quote}
> Add support for SFTP "filename-charset" extension
> -
>
> Key: SSHD-1132
> URL: https://issues.apache.org/jira/browse/SSHD-1132
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Assignee: Lyor Goldstein
>Priority: Minor
> Labels: SFTP, sftp
>
> See https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-16
--
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-1134) Review handling of InterruptedException in code
Lyor Goldstein created SSHD-1134: Summary: Review handling of InterruptedException in code Key: SSHD-1134 URL: https://issues.apache.org/jira/browse/SSHD-1134 Project: MINA SSHD Issue Type: Improvement Reporter: Lyor Goldstein See [Brian Goetz's treatise|https://www.ibm.com/developerworks/library/j-jtp05236/] -- 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-1135) Configurable sshd transfer threads
[
https://issues.apache.org/jira/browse/SSHD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293009#comment-17293009
]
Lyor Goldstein commented on SSHD-1135:
--
{quote}Once a socket has either been accepted or connected, the socket is
registered with a transfer thread
{quote}
I think this is incorrect - the socket is not registered with any specific
thread. There is a pool of thread along with an _Executor_ that assigns a
thread from it to serve a socket when data is detected on it. On the data has
been handled, the thread returns to the pool and is ready to serve some (maybe)
other socket.
{quote}I know if we use socketImplementation default (NIO2) there is a
configuration value called nio-workers. Will it serve our purpose?
{quote}
If I understand correctly the question then yes...
{quote}And if so what are the upper boundary limits for the value nio-worker
(Property.integer("nio-workers", Runtime.getRuntime().availableProcessors() +
X)
{quote}
Something like that, although difficult to say how large _X_ should be. While
the threads are mostly stuck on I/O to/from the socket, if there are too many
of them then the context switching overhead becomes a factor. Also, it depends
a lot on the traffic - if it is light, then no need for many threads.
> Configurable sshd transfer threads
> --
>
> Key: SSHD-1135
> URL: https://issues.apache.org/jira/browse/SSHD-1135
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Set the number of transfer threads. Once a socket has either been accepted or
> connected, the socket is registered with a transfer thread. This thread
> asynchronously performs all the IO for the socket. If all the permanent
> threads become fully loaded then additional threads will be created to handle
> additional connections and shutdown once they have no sockets to service.
>
> Is there any performance tuning parameter that we can use to leverage our
> above use case?
> I know if we use socketImplementation default (NIO2) there is a configuration
> value called {{nio-workers. Will it serve our purpose?}}
> And if so what are the upper boundary limits for the value nio-worker
>
> (Property.integer("nio-workers", Runtime.getRuntime().availableProcessors() +
> X)
--
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-1135) Configurable sshd transfer threads
[
https://issues.apache.org/jira/browse/SSHD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1135.
--
Resolution: Information Provided
> Configurable sshd transfer threads
> --
>
> Key: SSHD-1135
> URL: https://issues.apache.org/jira/browse/SSHD-1135
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Set the number of transfer threads. Once a socket has either been accepted or
> connected, the socket is registered with a transfer thread. This thread
> asynchronously performs all the IO for the socket. If all the permanent
> threads become fully loaded then additional threads will be created to handle
> additional connections and shutdown once they have no sockets to service.
>
> Is there any performance tuning parameter that we can use to leverage our
> above use case?
> I know if we use socketImplementation default (NIO2) there is a configuration
> value called {{nio-workers. Will it serve our purpose?}}
> And if so what are the upper boundary limits for the value nio-worker
>
> (Property.integer("nio-workers", Runtime.getRuntime().availableProcessors() +
> X)
--
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-1135) Configurable sshd transfer threads
[
https://issues.apache.org/jira/browse/SSHD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293818#comment-17293818
]
Lyor Goldstein commented on SSHD-1135:
--
{quote}
If all the threads in the pool are busy with other tasks, then the incoming
task shall wait. So increasing the NI02 shall it increase the thread pool size?
{quote}
I don't understand the question - which pool are you referring to ? What tasks ?
> Configurable sshd transfer threads
> --
>
> Key: SSHD-1135
> URL: https://issues.apache.org/jira/browse/SSHD-1135
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Set the number of transfer threads. Once a socket has either been accepted or
> connected, the socket is registered with a transfer thread. This thread
> asynchronously performs all the IO for the socket. If all the permanent
> threads become fully loaded then additional threads will be created to handle
> additional connections and shutdown once they have no sockets to service.
>
> Is there any performance tuning parameter that we can use to leverage our
> above use case?
> I know if we use socketImplementation default (NIO2) there is a configuration
> value called {{nio-workers. Will it serve our purpose?}}
> And if so what are the upper boundary limits for the value nio-worker
>
> (Property.integer("nio-workers", Runtime.getRuntime().availableProcessors() +
> X)
--
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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17295865#comment-17295865
]
Lyor Goldstein commented on SSHD-1118:
--
{quote}
It will soon be an issue for the compatibility of MINA SSHD with all OpenSSH
clients (using RSA keys)
RSA keys continue to work, assuming that the server's KEX enumerates the new
signature algorithms like rsa-sha2-256 or rsa-sha2-512.
{quote}
Again, how is this a MINA SSHD issue ? And AFAIK we do support {{
rsa-sha2-256}} and {{rsa-sha2-512}}.
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1125) Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
[
https://issues.apache.org/jira/browse/SSHD-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1125.
--
Fix Version/s: 2.7.0
Resolution: Fixed
> Provide a boundary on BufferedIoOutputStream writing to avoid memory overflow
> -
>
> Key: SSHD-1125
> URL: https://issues.apache.org/jira/browse/SSHD-1125
> Project: MINA SSHD
> Issue Type: Bug
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Major
> Labels: memory
> Fix For: 2.7.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Use an upper bound to the data pending in the {{BufferedIoOutputStream}}. The
> max data could be set to the max window size. Blocking until there is enough
> room should allow the client to read the data.
--
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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17295894#comment-17295894
]
Lyor Goldstein commented on SSHD-1118:
--
Indeed, but please bear in mind that {{server-sig-alg}} is an SSH KEX
+extension+ and not all clients support it.
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1133) Provide non-UTF8 charset encoding capability to SCP implementation
[ https://issues.apache.org/jira/browse/SSHD-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1133. -- Fix Version/s: 2.7.0 Resolution: Fixed > Provide non-UTF8 charset encoding capability to SCP implementation > -- > > Key: SSHD-1133 > URL: https://issues.apache.org/jira/browse/SSHD-1133 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein > Assignee: Lyor Goldstein >Priority: Minor > Fix For: 2.7.0 > > > Some non-standard clients/servers might employ non-UTF8 encoding - provide > some way to encode/decode these names on both sides of the SCP protocol -- 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-1135) Configurable sshd transfer threads
[
https://issues.apache.org/jira/browse/SSHD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17295898#comment-17295898
]
Lyor Goldstein commented on SSHD-1135:
--
While there are similarities and perhaps internal implementation as such, these
are 2 separate code flows.
> Configurable sshd transfer threads
> --
>
> Key: SSHD-1135
> URL: https://issues.apache.org/jira/browse/SSHD-1135
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Set the number of transfer threads. Once a socket has either been accepted or
> connected, the socket is registered with a transfer thread. This thread
> asynchronously performs all the IO for the socket. If all the permanent
> threads become fully loaded then additional threads will be created to handle
> additional connections and shutdown once they have no sockets to service.
>
> Is there any performance tuning parameter that we can use to leverage our
> above use case?
> I know if we use socketImplementation default (NIO2) there is a configuration
> value called {{nio-workers. Will it serve our purpose?}}
> And if so what are the upper boundary limits for the value nio-worker
>
> (Property.integer("nio-workers", Runtime.getRuntime().availableProcessors() +
> X)
--
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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17295905#comment-17295905
]
Lyor Goldstein commented on SSHD-1118:
--
Let's open up a separate issue for implementing {{server-sig-algs}} (if we have
not already done so...) and link it to this issue + add these comments...
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1136) Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on modulo size is not possible
[
https://issues.apache.org/jira/browse/SSHD-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1136:
Assignee: Lyor Goldstein
> Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on
> modulo size is not possible
> --
>
> Key: SSHD-1136
> URL: https://issues.apache.org/jira/browse/SSHD-1136
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
> Assignee: Lyor Goldstein
>Priority: Major
>
> After implementation of SSHD-1107 we configured the minimum modulo size of
> diffie-hellman-group-exchange-sha256 to 2048 bit and expected clients that
> doesn't support this minimum to not be able to connect.
> But what happens is that, those clients still can connect and this warning is
> logged:
> {code}
> chooseDH(DHGEXServer[diffie-hellman-group-exchange-sha256])[ShaftServerSession[null@/10.42.110.99:44222]][prf=1024,
> min=1024, max=1024] No suitable primes found, defaulting to DHG1
> {code}
> My understanding is, that this is a fallback to diffie-hellman-group1-sha1
> which is week, see https://www.openssh.com/legacy.html
> Mina should make this fallback configurable and not activate it by default.
--
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-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1137: Assignee: Lyor Goldstein > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Major > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false > leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, > which finally causes the opening to fail. > My assumption is that when setting the file attributes, the caller assumed > that "false" is a good choice as a default for a case when there is no > indication if links should be followed or not. But I would sa
[jira] [Updated] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1137: - Priority: Minor (was: Major) > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false > leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, > which finally causes the opening to fail. > My assumption is that when setting the file attributes, the caller assumed > that "false" is a good choice as a default for a case when there is no > indication if links should be followed or not. But I would sa
[jira] [Commented] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[
https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297528#comment-17297528
]
Lyor Goldstein commented on SSHD-1137:
--
{quote}
changing "false" into "true" in FileHandle, line 77, should do the trick.
{quote}
This is not cut-and-dry - there are (good) historical reasons why we use
{{NOFOLLOW_LINKS}} (has to do with correctly accessing symbolic links and
avoiding escape from the user's home directory). Perhaps a better solution
would be to detect that we are running on AIX (though I am not sure how...) and
avoid this flag and/or allow using an explicit configuration property (or
both). That being said, can you attach to this issue the value of the
{{os.name}} Java system property value for AIX - thx.
> IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH
> SFTP client
> -
>
> Key: SSHD-1137
> URL: https://issues.apache.org/jira/browse/SSHD-1137
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: SFTP-Server running on AIX
> OpenSSH SFTP client
> Reporter: Curd Reinert
>Assignee: Lyor Goldstein
>Priority: Minor
>
> When accessing an SFTP server running on AIX with an OpenSSH SFTP client
> (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well),
> I get the following exception:
> [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class:
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method:
> handleSetFileAttributeFailure Line: 2645 -
> /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread
> =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001,
> pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv]
> posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure
> details
> java.io.IOException: NOFOLLOW_LINKS is not supported on this platform
> at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272)
>
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541)
> at
> org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344)
> at
> de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> I've had a look into the source code. It seems the permissions requested by
> the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not
> supported by the file systems. This fails equally on Windows, Linux or AIX
> for an initial open, and therefore the catch block in [FileHandle (line
> 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75]
> is reached. Here the openFile for the channel is repeated without file
> att
[jira] [Commented] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297529#comment-17297529 ] Lyor Goldstein commented on SSHD-1137: -- BTW, there might be other O/S dependent issues - e.g., can we treat AIX as if it is Linux ? E.g., what is the file separator ? Does it support symbolic links ? Does it support user/group/owner permissions - etc... Fixing this issue might not be enough since we have a few places in the code that are O/S specific and further modifications might be needed to support AIX. > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false >
[jira] [Updated] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1137: - Labels: AIX aix (was: ) > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > Labels: AIX, aix > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false > leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, > which finally causes the opening to fail. > My assumption is that when setting the file attributes, the caller assumed > that "false" is a good choice as a default for a case when there is no > indication if links should be followed or not. But I would
[jira] [Commented] (SSHD-1138) Setting compression for Client -> Server and vice versa streams
[
https://issues.apache.org/jira/browse/SSHD-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297531#comment-17297531
]
Lyor Goldstein commented on SSHD-1138:
--
See {{SshClient/Server#setCompressionFactories}}
> Setting compression for Client -> Server and vice versa streams
> ---
>
> Key: SSHD-1138
> URL: https://issues.apache.org/jira/browse/SSHD-1138
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Hello,
> Can we set the preferred compression to ZIP/ZLIB for the Server->Client
> stream and vice versa. If you can guide me to the exact API that will be
> helpful
> Thanks,
> Susmit
--
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-1138) Setting compression for Client -> Server and vice versa streams
[ https://issues.apache.org/jira/browse/SSHD-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1138. -- Resolution: Information Provided > Setting compression for Client -> Server and vice versa streams > --- > > Key: SSHD-1138 > URL: https://issues.apache.org/jira/browse/SSHD-1138 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > Hello, > Can we set the preferred compression to ZIP/ZLIB for the Server->Client > stream and vice versa. If you can guide me to the exact API that will be > helpful > Thanks, > Susmit -- 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-1138) Setting compression for Client -> Server and vice versa streams
[
https://issues.apache.org/jira/browse/SSHD-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297531#comment-17297531
]
Lyor Goldstein edited comment on SSHD-1138 at 3/8/21, 5:04 PM:
---
See {{SshClient/Server#setCompressionFactories}} - note that it only means that
the client/server publishes the fact that it supports these factories. Whether
they will be used or not depends on the KEX options negotiation
was (Author: lgoldstein):
See {{SshClient/Server#setCompressionFactories}}
> Setting compression for Client -> Server and vice versa streams
> ---
>
> Key: SSHD-1138
> URL: https://issues.apache.org/jira/browse/SSHD-1138
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> Hello,
> Can we set the preferred compression to ZIP/ZLIB for the Server->Client
> stream and vice versa. If you can guide me to the exact API that will be
> helpful
> Thanks,
> Susmit
--
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-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300130#comment-17300130
]
Lyor Goldstein commented on SSHD-1141:
--
[~iwienand] I don't have an exact timeline for when we will get around to doing
this, but I believe the current code already contains hooks put in place for
KEX extension negotiation that you can probably use to implement this if you
are willing to do so. This way we can kill 2 birds with 1 stone - you can get a
solution for this issue faster and we can gain a contribution to the MINA SSHD
code - something we encourage our users to do...
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300398#comment-17300398
]
Lyor Goldstein commented on SSHD-1123:
--
On first look it looks fine - I will give it a more thorough look though and if
nothing special pops up I will be more that happy to merge it in.
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
>Priority: Major
> Attachments: download.js, package.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to why this was
> changed. As I understand the SSH specification, the packet size is a maximum
> packet size. So, it should be ok to send a smaller packet.
> This is the code causing the issue in ChannelAsyncOutputStream.
> {code:java}
> if (total > remoteWindowSize) {
> // if we have a big message and there is enough space, send the next chunk
> if (remoteWindowSize >= packetSize) {
> // send the first chunk as we have enough space in the window
> length = packetSize;
> } else {
> // do not chunk when the window is smaller than the packet size
> length = 0;
> // do a defensive copy in case the user reuses the buffer
> IoWriteFutureImpl f = new IoWriteFutureImpl(future.getId(), new
> ByteArrayBuffer(buffer.getCompactData()));
> f.addListener(w -> future.setValue(w.getException() != null ?
> w.getException() : w.isWritten()));
> pendingWrite.set(f);
> if (log.isTraceEnabled()) {
> log.trace("doWriteIfPossible({})[resume={}] waiting for window
> space {}",
> this, resume, remoteWindowSize);
> }
> }
> {code}
> I have attached code for reproducing the issue. To run you need node.js and
> npm installed:
> {code}
> npm install
> nodejs download.js
> {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] [Comment Edited] (SSHD-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300398#comment-17300398
]
Lyor Goldstein edited comment on SSHD-1123 at 3/12/21, 4:04 PM:
On first look it looks fine - I will give it a more thorough look though and if
nothing special pops up I will be more than happy to merge it in.
was (Author: lgoldstein):
On first look it looks fine - I will give it a more thorough look though and if
nothing special pops up I will be more that happy to merge it in.
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
>Priority: Major
> Attachments: download.js, package.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to why this was
> changed. As I understand the SSH specification, the packet size is a maximum
> packet size. So, it should be ok to send a smaller packet.
> This is the code causing the issue in ChannelAsyncOutputStream.
> {code:java}
> if (total > remoteWindowSize) {
> // if we have a big message and there is enough space, send the next chunk
> if (remoteWindowSize >= packetSize) {
> // send the first chunk as we have enough space in the window
> length = packetSize;
> } else {
> // do not chunk when the window is smaller than the packet size
> length = 0;
> // do a defensive copy in case the user reuses the buffer
> IoWriteFutureImpl f = new IoWriteFutureImpl(future.getId(), new
> ByteArrayBuffer(buffer.getCompactData()));
> f.addListener(w -> future.setValue(w.getException() != null ?
> w.getException() : w.isWritten()));
> pendingWrite.set(f);
> if (log.isTraceEnabled()) {
> log.trace("doWriteIfPossible({})[resume={}] waiting for window
> space {}",
> this, resume, remoteWindowSize);
> }
> }
> {code}
> I have attached code for reproducing the issue. To run you need node.js and
> npm installed:
> {code}
> npm install
> nodejs download.js
> {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-1140) Questions about IoServiceFactoryFactory
[
https://issues.apache.org/jira/browse/SSHD-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301240#comment-17301240
]
Lyor Goldstein commented on SSHD-1140:
--
There are lots (and I mean +lots+) of properties and parameters that can be
used to control and configure the code's behavior. I am sorry, but I do not
remember all of them off hand. That being said, I did a quick search on the
ones you mentioned
{quote}nioWorkers
maxPacketSize
windowSize
{quote}
Applicable to all I/O factories
{quote}socketSendBuffer
socketReceiveBuffer
socketBacklog
nio2readBuffer - and others...
{quote}
Applicable only to NIO2
{quote}and other sever related tuning parameters
{quote}
Like I said, there are a +lot+ of them - I strongly recommend reading the
documentation at the official site, as well as look for the various
{{Property}} usages in the code. Please remember that many of the tuning
parameters have impacts that need to be considered very carefully, as well as
possible interactions with other such parameters.
> Questions about IoServiceFactoryFactory
> ---
>
> Key: SSHD-1140
> URL: https://issues.apache.org/jira/browse/SSHD-1140
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
>
> IoServiceFactoryFactory ioServiceFactory =
> BuiltinIoServiceFactoryFactories.NIO2/MINA/NETTY.create();
> We can have 3 flavors of ioServiceFactory
> My question is are *all* the below parameters applicable for all 3
> IOFactories (.NIO2/MINA/NETTY) ?
> nioWorkers *(is it applicable only to NIO2 or all 3?)*
> maxPacketSize
> windowSize
> socketSendBuffer
> socketReceiveBuffer
> socketBacklog
> *nio2readBuffer (is it applicable only to NIO2?)*
> and other sever related tuning parameters
>
>
--
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-1140) Questions about IoServiceFactoryFactory
[ https://issues.apache.org/jira/browse/SSHD-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1140. -- Resolution: Information Provided > Questions about IoServiceFactoryFactory > --- > > Key: SSHD-1140 > URL: https://issues.apache.org/jira/browse/SSHD-1140 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar >Priority: Critical > > IoServiceFactoryFactory ioServiceFactory = > BuiltinIoServiceFactoryFactories.NIO2/MINA/NETTY.create(); > We can have 3 flavors of ioServiceFactory > My question is are *all* the below parameters applicable for all 3 > IOFactories (.NIO2/MINA/NETTY) ? > nioWorkers *(is it applicable only to NIO2 or all 3?)* > maxPacketSize > windowSize > socketSendBuffer > socketReceiveBuffer > socketBacklog > *nio2readBuffer (is it applicable only to NIO2?)* > and other sever related tuning parameters > > -- 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-1142) To pick up Mac/Cipher preferred values out of the default list
[
https://issues.apache.org/jira/browse/SSHD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302743#comment-17302743
]
Lyor Goldstein commented on SSHD-1142:
--
The order in the list defines the preference - the default one is the
recommended, but you can override it:
{code:java}
sshd.setMacFactoriesNames(Arrays.asList("mac1", "mac2", "mac3", ...));
{code}
I do want to remind you though that the actual used value depends on the
client's preferences, so even though the server lists MAC1 as the most
preferred one, if the client lists MAC5 as its preferred one then MAC5 will be
used. In other words, the only way to force a client (or server) to use a
specific MAC (or cipher or key) is to list only that MAC - but then clients (or
servers) who do not support it will not be able to connect.
> To pick up Mac/Cipher preferred values out of the default list
> --
>
> Key: SSHD-1142
> URL: https://issues.apache.org/jira/browse/SSHD-1142
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Lyor,
> I want to use a preferred value while configuring sftp adapter for both
> cipher and mac algos:
> System.out.println(sshd.getMacFactories());
> [hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
> hmac-sha1-...@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1, hmac-md5,
> hmac-sha1-96, hmac-md5-96]
> Now if the customer wants a preferred value of *hmac-md5* how can I give it
> priority compared to all other default ciphers?
> sshd.setMacFactoriesNames(Arrays.asList("hmac-md5"));
> This only sets to hmac-md5, but the list should contain all only the hmac-md5
> will be in the priority order 1
> *[ hmac-md5]*
> [https://github.com/apache/mina-sshd/blob/master/docs/server-setup.md#configuring-ciphers-macs-digest]
> *One can configure other security components using built-in factories the
> same way. It is important to remember though that the order of the factories
> is important as it affects the key exchange phase where the client and server
> decide what options to use out of each peer's reported preferences.*
>
>
--
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-1142) To pick up Mac/Cipher preferred values out of the default list
[
https://issues.apache.org/jira/browse/SSHD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1142.
--
Resolution: Information Provided
> To pick up Mac/Cipher preferred values out of the default list
> --
>
> Key: SSHD-1142
> URL: https://issues.apache.org/jira/browse/SSHD-1142
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Lyor,
> I want to use a preferred value while configuring sftp adapter for both
> cipher and mac algos:
> System.out.println(sshd.getMacFactories());
> [hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
> hmac-sha1-...@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1, hmac-md5,
> hmac-sha1-96, hmac-md5-96]
> Now if the customer wants a preferred value of *hmac-md5* how can I give it
> priority compared to all other default ciphers?
> sshd.setMacFactoriesNames(Arrays.asList("hmac-md5"));
> This only sets to hmac-md5, but the list should contain all only the hmac-md5
> will be in the priority order 1
> *[ hmac-md5]*
> [https://github.com/apache/mina-sshd/blob/master/docs/server-setup.md#configuring-ciphers-macs-digest]
> *One can configure other security components using built-in factories the
> same way. It is important to remember though that the order of the factories
> is important as it affects the key exchange phase where the client and server
> decide what options to use out of each peer's reported preferences.*
>
>
--
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-1142) To pick up Mac/Cipher preferred values out of the default list
[
https://issues.apache.org/jira/browse/SSHD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303670#comment-17303670
]
Lyor Goldstein commented on SSHD-1142:
--
yes and no - please note that there are +2+ MAC/cipher/compressions being
negotiated - one for data from client to server and the other for the other way
around. While you can influence one of them (depending on whether you are the
client or the server), the other is chosen by the peer according to its
preferences. I strongly recommend re-reading [RFC 4253 - section 7.1 -
Algorithm Negotiation|https://tools.ietf.org/html/rfc4253#section-7.1]
> To pick up Mac/Cipher preferred values out of the default list
> --
>
> Key: SSHD-1142
> URL: https://issues.apache.org/jira/browse/SSHD-1142
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Lyor,
> I want to use a preferred value while configuring sftp adapter for both
> cipher and mac algos:
> System.out.println(sshd.getMacFactories());
> [hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
> hmac-sha1-...@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1, hmac-md5,
> hmac-sha1-96, hmac-md5-96]
> Now if the customer wants a preferred value of *hmac-md5* how can I give it
> priority compared to all other default ciphers?
> sshd.setMacFactoriesNames(Arrays.asList("hmac-md5"));
> This only sets to hmac-md5, but the list should contain all only the hmac-md5
> will be in the priority order 1
> *[ hmac-md5]*
> [https://github.com/apache/mina-sshd/blob/master/docs/server-setup.md#configuring-ciphers-macs-digest]
> *One can configure other security components using built-in factories the
> same way. It is important to remember though that the order of the factories
> is important as it affects the key exchange phase where the client and server
> decide what options to use out of each peer's reported preferences.*
>
>
--
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-1142) To pick up Mac/Cipher preferred values out of the default list
[
https://issues.apache.org/jira/browse/SSHD-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303670#comment-17303670
]
Lyor Goldstein edited comment on SSHD-1142 at 3/17/21, 7:10 PM:
yes and no - please note that there are +2+ MAC/cipher/compressions being
negotiated - one for data from client to server and the other for the other way
around. While you can influence one of them (depending on whether you are the
client or the server), the other is chosen by the peer according to its
preferences. I strongly recommend re-reading [RFC 4253 - section 7.1 -
Algorithm Negotiation|https://tools.ietf.org/html/rfc4253#section-7.1]
{quote}
The chosen MAC algorithm MUST be the first algorithm on the client's name-list
that is also on the server's name-list.
{quote}
Which means that even if you place MAC1 to be 1st on the server side, it might
not be chosen if the client declares MAC2 to be its most be preferred (assuming
it is also on the server's list). This is because the +client+ ultimately
chooses what to use out of the server's declared preferences/capabilities
was (Author: lgoldstein):
yes and no - please note that there are +2+ MAC/cipher/compressions being
negotiated - one for data from client to server and the other for the other way
around. While you can influence one of them (depending on whether you are the
client or the server), the other is chosen by the peer according to its
preferences. I strongly recommend re-reading [RFC 4253 - section 7.1 -
Algorithm Negotiation|https://tools.ietf.org/html/rfc4253#section-7.1]
> To pick up Mac/Cipher preferred values out of the default list
> --
>
> Key: SSHD-1142
> URL: https://issues.apache.org/jira/browse/SSHD-1142
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Lyor,
> I want to use a preferred value while configuring sftp adapter for both
> cipher and mac algos:
> System.out.println(sshd.getMacFactories());
> [hmac-sha2-256-...@openssh.com, hmac-sha2-512-...@openssh.com,
> hmac-sha1-...@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1, hmac-md5,
> hmac-sha1-96, hmac-md5-96]
> Now if the customer wants a preferred value of *hmac-md5* how can I give it
> priority compared to all other default ciphers?
> sshd.setMacFactoriesNames(Arrays.asList("hmac-md5"));
> This only sets to hmac-md5, but the list should contain all only the hmac-md5
> will be in the priority order 1
> *[ hmac-md5]*
> [https://github.com/apache/mina-sshd/blob/master/docs/server-setup.md#configuring-ciphers-macs-digest]
> *One can configure other security components using built-in factories the
> same way. It is important to remember though that the order of the factories
> is important as it affects the key exchange phase where the client and server
> decide what options to use out of each peer's reported preferences.*
>
>
--
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-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1123 started by Lyor Goldstein.
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
> Assignee: Lyor Goldstein
>Priority: Major
> Attachments: download.js, package.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to why this was
> changed. As I understand the SSH specification, the packet size is a maximum
> packet size. So, it should be ok to send a smaller packet.
> This is the code causing the issue in ChannelAsyncOutputStream.
> {code:java}
> if (total > remoteWindowSize) {
> // if we have a big message and there is enough space, send the next chunk
> if (remoteWindowSize >= packetSize) {
> // send the first chunk as we have enough space in the window
> length = packetSize;
> } else {
> // do not chunk when the window is smaller than the packet size
> length = 0;
> // do a defensive copy in case the user reuses the buffer
> IoWriteFutureImpl f = new IoWriteFutureImpl(future.getId(), new
> ByteArrayBuffer(buffer.getCompactData()));
> f.addListener(w -> future.setValue(w.getException() != null ?
> w.getException() : w.isWritten()));
> pendingWrite.set(f);
> if (log.isTraceEnabled()) {
> log.trace("doWriteIfPossible({})[resume={}] waiting for window
> space {}",
> this, resume, remoteWindowSize);
> }
> }
> {code}
> I have attached code for reproducing the issue. To run you need node.js and
> npm installed:
> {code}
> npm install
> nodejs download.js
> {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] [Assigned] (SSHD-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1123:
Assignee: Lyor Goldstein
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
> Assignee: Lyor Goldstein
>Priority: Major
> Attachments: download.js, package.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to why this was
> changed. As I understand the SSH specification, the packet size is a maximum
> packet size. So, it should be ok to send a smaller packet.
> This is the code causing the issue in ChannelAsyncOutputStream.
> {code:java}
> if (total > remoteWindowSize) {
> // if we have a big message and there is enough space, send the next chunk
> if (remoteWindowSize >= packetSize) {
> // send the first chunk as we have enough space in the window
> length = packetSize;
> } else {
> // do not chunk when the window is smaller than the packet size
> length = 0;
> // do a defensive copy in case the user reuses the buffer
> IoWriteFutureImpl f = new IoWriteFutureImpl(future.getId(), new
> ByteArrayBuffer(buffer.getCompactData()));
> f.addListener(w -> future.setValue(w.getException() != null ?
> w.getException() : w.isWritten()));
> pendingWrite.set(f);
> if (log.isTraceEnabled()) {
> log.trace("doWriteIfPossible({})[resume={}] waiting for window
> space {}",
> this, resume, remoteWindowSize);
> }
> }
> {code}
> I have attached code for reproducing the issue. To run you need node.js and
> npm installed:
> {code}
> npm install
> nodejs download.js
> {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] [Resolved] (SSHD-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1123.
--
Fix Version/s: 2.7.0
Resolution: Fixed
Hi [~ahuegendp] - thanks for the contribution - merged it in with
acknowledgement (see
[commit|https://github.com/apache/mina-sshd/commit/098760248c37e628723529c2c49c5a353606ff23]).
I also took the liberty of adding +configurable+ support for this feature -
see {{ChannelSession#isSendChunkIfRemoteWindowIsSmallerThanPacketSize}}.
Basically, this enables you to register a {{SessionListener}} on the server
side, examine each new session's reported client version and then set the
relevant properties:
{code:java}
SshServer sshd= ...setup server...
sshd.addSessionListener(new SessionListener() {
@Override
public void sessionPeerIdentificationReceived(
Session session, String version, List extraLines) {
if (isVersionOfInterest(version)) {
CoreModuleProperties.ASYNC_SERVER_STDOUT_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
CoreModuleProperties.ASYNC_SERVER_STDERR_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
}
}
})
{code}
This way you don't have to extend {{ChannelSession}} - which is not an easy task
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.7.0
>
> Attachments: download.js, package.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to why this was
> changed. As I understand the SSH specification, the packet size is a maximum
> packet size. So, it should be ok to send a smaller packet.
> This is the code causing the issue in ChannelAsyncOutputStream.
> {code:java}
> if (total > remoteWindowSize) {
> // if we have a big message and there is enough space, send the next chunk
> if (remoteWindowSize >= packetSize) {
> // send the first chunk as we have enough space in the window
> length = packetSize;
> } else {
> // do not chunk when the window is smaller than the packet size
> length = 0;
> // do a defensive copy in case the user reuses the buffer
> IoWriteFutureImpl f = new IoWriteFutureImpl(future.getId(), new
> ByteArrayBuffer(buffer.getCompactData()));
> f.addListener(w -> future.setValue(w.getException() != null ?
> w.getException() : w.isWritten()));
> pendingWrite.set(f);
> if (log.isTraceEnabled()) {
> log.trace("doWriteIfPossible({})[resume={}] waiting for window
> space {}",
> this, resume, remoteWindowSize);
> }
> }
> {code}
> I have attached code for reproducing the issue. To run you n
[jira] [Comment Edited] (SSHD-1123) ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when the remote window is smaller than the packet size
[
https://issues.apache.org/jira/browse/SSHD-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305362#comment-17305362
]
Lyor Goldstein edited comment on SSHD-1123 at 3/20/21, 8:15 AM:
Hi [~ahuegendp] - thanks for the contribution - merged it in with
acknowledgement (see
[commit|https://github.com/apache/mina-sshd/commit/098760248c37e628723529c2c49c5a353606ff23]).
I also took the liberty of adding +configurable+ support for this feature -
see {{ChannelSession#isSendChunkIfRemoteWindowIsSmallerThanPacketSize}}.
Basically, this enables you to register a {{SessionListener}} on the server
side, examine each new session's reported client version and then set the
relevant properties:
{code:java}
SshServer sshd= ...setup server...
sshd.addSessionListener(new SessionListener() {
@Override
public void sessionPeerIdentificationReceived(
Session session, String version, List extraLines) {
if (isVersionOfInterest(version)) {
CoreModuleProperties.ASYNC_SERVER_STDOUT_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
CoreModuleProperties.ASYNC_SERVER_STDERR_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
}
}
})
{code}
This way you don't have to extend {{ChannelSession}} - which is not an easy
task. BTW, you can also set this +globally+ by applying the properties to the
_sshd_ server instance instead of registering a {{SessionListener}}.
was (Author: lgoldstein):
Hi [~ahuegendp] - thanks for the contribution - merged it in with
acknowledgement (see
[commit|https://github.com/apache/mina-sshd/commit/098760248c37e628723529c2c49c5a353606ff23]).
I also took the liberty of adding +configurable+ support for this feature -
see {{ChannelSession#isSendChunkIfRemoteWindowIsSmallerThanPacketSize}}.
Basically, this enables you to register a {{SessionListener}} on the server
side, examine each new session's reported client version and then set the
relevant properties:
{code:java}
SshServer sshd= ...setup server...
sshd.addSessionListener(new SessionListener() {
@Override
public void sessionPeerIdentificationReceived(
Session session, String version, List extraLines) {
if (isVersionOfInterest(version)) {
CoreModuleProperties.ASYNC_SERVER_STDOUT_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
CoreModuleProperties.ASYNC_SERVER_STDERR_CHUNK_BELOW_WINDOW_SIZE.set(session,
true);
}
}
})
{code}
This way you don't have to extend {{ChannelSession}} - which is not an easy task
> ChannelAsyncOutputStream breaks downloads of sftp client by not chunking when
> the remote window is smaller than the packet size
> ---
>
> Key: SSHD-1123
> URL: https://issues.apache.org/jira/browse/SSHD-1123
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
> Reporter: Achim Hügen
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.7.0
>
> Attachments: download.js, package.json
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After the upgrade from 2.4.0 to 2.6.0 we experienced issues with a SFTP
> Client used in our test automation (Node.JS ssh2). The download of a file
> hangs after about 1MB of 5MB has been downloaded.
> Although this ssh2 version (0.4.15) is admittedly quite old and meanwhile a
> fix is available, we are reluctant to rollout 2.6.0 to production where a
> multitude of sftp clients is used by customers and might experience the same
> issue.
> Short story: the specific ssh2 client only adjusts its local windows size, if
> the window size is down to 0. But mina in version 2.6 usually will stop
> sending data before. So both parties are waiting for each other.
> Example: the window size of the client is 1048576 and packet size is 32768.
> After successfully requesting 1015808 of file data, when the clients reads
> the next 32768 bytes, the remote window size as calculated by the MINA is
> 31706 bytes. Thus the data to send is larger then the remaining space in the
> window.
> The old logic in 2.4 just filled the window to the brim by chunking the data.
> Some newly introduced logic (see
> https://github.com/apache/mina-sshd/commit/536d066349f41a6f6a7f95501506cd1ba66dad7a)
> now decides to stop sending more data, because the remote window size is
> smaller then the packet size.
> The server waits for the client to send a SSH_MSG_CHANNEL_WINDOW_ADJUST and
> the client doesn't do this, because the window still has some space.
> Unfortunately the commit doesn't contain any reference to wh
[jira] [Commented] (SSHD-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305364#comment-17305364
]
Lyor Goldstein commented on SSHD-1141:
--
Agree - this is clearly stated in RFC 8308
{quote}
Neither party needs to wait for the other's SSH_MSG_KEXINIT in order to decide
whether to send the appropriate indicator in its own SSH_MSG_KEXINIT.
{quote}
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306796#comment-17306796
]
Lyor Goldstein commented on SSHD-1141:
--
{quote}
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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] [Issue Comment Deleted] (SSHD-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1141:
-
Comment: was deleted
(was: {quote})
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306808#comment-17306808
]
Lyor Goldstein commented on SSHD-1141:
--
{quote}
Should the client do that?
{quote}
Good question - on one hand, it violates RFC 4252 and may present a security
vulnerability. On the other hand, we might not want to prevent our users from
connecting to _github_. Here is what I suggest we do:
* Client remembers chosen key when it sends {{SSH_MSG_USERAUTH_REQUEST}} by
setting a session attribute (remember to clear it regardless of whether
authentication eventually succeeds or not)
* When it receives {{SSH_MSG_USERAUTH_PK_OK}} it checks if the echoed key
matches the selected one.
* If yes, then all is well. if not, then it consults a +configuration
{{Property}}+ whether to be strict (default) or not.
* If strict mode - then fail the authentication attempt (with an appropriate
log message)
* Otherwise, check if the echoed key is of the +same "type"+ (RSA in this
case). If not, then (obviously) fail the attempt, otherwise issue a log warning
and proceed (as the current code does).
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1148) Question on thread handling with IOservicefactory as NIO2
[ https://issues.apache.org/jira/browse/SSHD-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1148 started by Lyor Goldstein. > Question on thread handling with IOservicefactory as NIO2 > - > > Key: SSHD-1148 > URL: https://issues.apache.org/jira/browse/SSHD-1148 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar > Assignee: Lyor Goldstein >Priority: Major > > Hello Lyor/Team, > I am laterally performing 2 PUT operations, one from ssh terminal and another > from WinSCP. During the process, I am printing the thread name/id. For both > the case, I am getting a thread name as: > *sshd-SftpSubsystem-thread-1* > Despite being the operation being parallel executed, as both the operation > are parallelly executed, a single thread does the same operation may be > because of 2 different sessions, is there any way to pass an executor thread > pool to *SshServer* so we can see different thread working parallelly. May be > my understanding is wrong, can you please guide me > *sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5), > true);* > Will this spawn 5 parallel threads, and will be shut down gracefully as the > boolean is set to *true* > If it's a single thread model then if we use NioWorker threads as 2, and the > number of cores if I have 4 so total will be 6, so now as 1 core is occupied > with that single thread, will the remaining 5 cores will sit idle? -- 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-1148) Question on thread handling with IOservicefactory as NIO2
[ https://issues.apache.org/jira/browse/SSHD-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1148: Assignee: Lyor Goldstein > Question on thread handling with IOservicefactory as NIO2 > - > > Key: SSHD-1148 > URL: https://issues.apache.org/jira/browse/SSHD-1148 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar > Assignee: Lyor Goldstein >Priority: Major > > Hello Lyor/Team, > I am laterally performing 2 PUT operations, one from ssh terminal and another > from WinSCP. During the process, I am printing the thread name/id. For both > the case, I am getting a thread name as: > *sshd-SftpSubsystem-thread-1* > Despite being the operation being parallel executed, as both the operation > are parallelly executed, a single thread does the same operation may be > because of 2 different sessions, is there any way to pass an executor thread > pool to *SshServer* so we can see different thread working parallelly. May be > my understanding is wrong, can you please guide me > *sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5), > true);* > Will this spawn 5 parallel threads, and will be shut down gracefully as the > boolean is set to *true* > If it's a single thread model then if we use NioWorker threads as 2, and the > number of cores if I have 4 so total will be 6, so now as 1 core is occupied > with that single thread, will the remaining 5 cores will sit idle? -- 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-1148) Question on thread handling with IOservicefactory as NIO2
[
https://issues.apache.org/jira/browse/SSHD-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306830#comment-17306830
]
Lyor Goldstein commented on SSHD-1148:
--
{quote}Despite being the operation being parallel executed, as both the
operation are parallelly executed, a single thread does the same operation
{quote}
It only seems this way - there is actually a +dedicated thread+ for each
{{SftpSubsystem}} instance running on the server side. The reason you see the
same thread name is because of this code:
{code:java}
public SftpSubsystem(ChannelSession channel, SftpSubsystemConfigurator
configurator) {
super(channel, configurator);
CloseableExecutorService executorService =
configurator.getExecutorService();
if (executorService == null) {
this.executorService =
ThreadUtils.newSingleThreadExecutor(getClass().getSimpleName());
} else {
this.executorService = executorService;
}
}
{code}
As you can see. the argument to {{ThreadUtils.newSingleThreadExecutor}} is the
class name - which is always {{SftpSubsystem}} - therefore when the executor
derives its name, it always gets the same result. Thanks for bringing this to
our intention - I will fix this.
{quote}is there any way to pass an executor thread pool to SshServer so we can
see different thread working parallelly.
{quote}
No through {{SshServer}} but rather through the {{SftpSubsystemFactory}} - but
like I said, you do have threads working in parallel - it just doesn't look
like this - so I would not recommend it (unless you want to manage your own
pool for some reason)
{quote}sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5),
true);
Will this spawn 5 parallel threads, and will be shut down gracefully as the
boolean is set to true
{quote}
No - the scheduled executors are used for something else - e.g., idle timeout,
heartbeat
{quote}If it's a single thread model then if we use NioWorker threads as 2, and
the number of cores if I have 4 so total will be 6, so now as 1 core is
occupied with that single thread, will the remaining 5 cores will sit idle?
{quote}
(a) it definitely is +not+ a single thread model and (b) {{NioWorker}} threads
affect +all+ SSH sessions and their behavior and not just SFTP.
> Question on thread handling with IOservicefactory as NIO2
> -
>
> Key: SSHD-1148
> URL: https://issues.apache.org/jira/browse/SSHD-1148
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Major
>
> Hello Lyor/Team,
> I am laterally performing 2 PUT operations, one from ssh terminal and another
> from WinSCP. During the process, I am printing the thread name/id. For both
> the case, I am getting a thread name as:
> *sshd-SftpSubsystem-thread-1*
> Despite being the operation being parallel executed, as both the operation
> are parallelly executed, a single thread does the same operation may be
> because of 2 different sessions, is there any way to pass an executor thread
> pool to *SshServer* so we can see different thread working parallelly. May be
> my understanding is wrong, can you please guide me
> *sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5),
> true);*
> Will this spawn 5 parallel threads, and will be shut down gracefully as the
> boolean is set to *true*
> If it's a single thread model then if we use NioWorker threads as 2, and the
> number of cores if I have 4 so total will be 6, so now as 1 core is occupied
> with that single thread, will the remaining 5 cores will sit idle?
--
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-1148) Question on thread handling with IOservicefactory as NIO2
[
https://issues.apache.org/jira/browse/SSHD-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306830#comment-17306830
]
Lyor Goldstein edited comment on SSHD-1148 at 3/23/21, 7:24 AM:
{quote}Despite being the operation being parallel executed, as both the
operation are parallelly executed, a single thread does the same operation
{quote}
It only seems this way - there is actually a +dedicated thread+ for each
{{SftpSubsystem}} instance running on the server side. The reason you see the
same thread name is because of this code:
{code:java}
public SftpSubsystem(ChannelSession channel, SftpSubsystemConfigurator
configurator) {
super(channel, configurator);
CloseableExecutorService executorService =
configurator.getExecutorService();
if (executorService == null) {
this.executorService =
ThreadUtils.newSingleThreadExecutor(getClass().getSimpleName());
} else {
this.executorService = executorService;
}
}
{code}
As you can see. the argument to {{ThreadUtils.newSingleThreadExecutor}} is the
class name - which is always {{SftpSubsystem}} - therefore when the executor
derives its name, it always gets the same result. Thanks for bringing this to
our intention - I will fix this.
{quote}is there any way to pass an executor thread pool to SshServer so we can
see different thread working parallelly.
{quote}
Not through {{SshServer}} but rather through the {{SftpSubsystemFactory}} - but
like I said, you do have threads working in parallel - it just doesn't look
like this - so I would not recommend it (unless you want to manage your own
pool for some reason)
{quote}sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5),
true);
Will this spawn 5 parallel threads, and will be shut down gracefully as the
boolean is set to true
{quote}
No - the scheduled executors are used for something else - e.g., idle timeout,
heartbeat
{quote}If it's a single thread model then if we use NioWorker threads as 2, and
the number of cores if I have 4 so total will be 6, so now as 1 core is
occupied with that single thread, will the remaining 5 cores will sit idle?
{quote}
(a) it definitely is +not+ a single thread model and (b) {{NioWorker}} threads
affect +all+ SSH sessions and their behavior and not just SFTP.
was (Author: lgoldstein):
{quote}Despite being the operation being parallel executed, as both the
operation are parallelly executed, a single thread does the same operation
{quote}
It only seems this way - there is actually a +dedicated thread+ for each
{{SftpSubsystem}} instance running on the server side. The reason you see the
same thread name is because of this code:
{code:java}
public SftpSubsystem(ChannelSession channel, SftpSubsystemConfigurator
configurator) {
super(channel, configurator);
CloseableExecutorService executorService =
configurator.getExecutorService();
if (executorService == null) {
this.executorService =
ThreadUtils.newSingleThreadExecutor(getClass().getSimpleName());
} else {
this.executorService = executorService;
}
}
{code}
As you can see. the argument to {{ThreadUtils.newSingleThreadExecutor}} is the
class name - which is always {{SftpSubsystem}} - therefore when the executor
derives its name, it always gets the same result. Thanks for bringing this to
our intention - I will fix this.
{quote}is there any way to pass an executor thread pool to SshServer so we can
see different thread working parallelly.
{quote}
No through {{SshServer}} but rather through the {{SftpSubsystemFactory}} - but
like I said, you do have threads working in parallel - it just doesn't look
like this - so I would not recommend it (unless you want to manage your own
pool for some reason)
{quote}sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5),
true);
Will this spawn 5 parallel threads, and will be shut down gracefully as the
boolean is set to true
{quote}
No - the scheduled executors are used for something else - e.g., idle timeout,
heartbeat
{quote}If it's a single thread model then if we use NioWorker threads as 2, and
the number of cores if I have 4 so total will be 6, so now as 1 core is
occupied with that single thread, will the remaining 5 cores will sit idle?
{quote}
(a) it definitely is +not+ a single thread model and (b) {{NioWorker}} threads
affect +all+ SSH sessions and their behavior and not just SFTP.
> Question on thread handling with IOservicefactory as NIO2
> -
>
> Key: SSHD-1148
> URL: https://issues.apache.org/jira/browse/SSHD-1148
> Project: MINA SSHD
> Issue Type: Question
> Reporter: Susmit Sarkar
>
[jira] [Resolved] (SSHD-1148) Question on thread handling with IOservicefactory as NIO2
[ https://issues.apache.org/jira/browse/SSHD-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1148. -- Fix Version/s: 2.7.0 Resolution: Fixed > Question on thread handling with IOservicefactory as NIO2 > - > > Key: SSHD-1148 > URL: https://issues.apache.org/jira/browse/SSHD-1148 > Project: MINA SSHD > Issue Type: Question >Reporter: Susmit Sarkar > Assignee: Lyor Goldstein >Priority: Major > Fix For: 2.7.0 > > > Hello Lyor/Team, > I am laterally performing 2 PUT operations, one from ssh terminal and another > from WinSCP. During the process, I am printing the thread name/id. For both > the case, I am getting a thread name as: > *sshd-SftpSubsystem-thread-1* > Despite being the operation being parallel executed, as both the operation > are parallelly executed, a single thread does the same operation may be > because of 2 different sessions, is there any way to pass an executor thread > pool to *SshServer* so we can see different thread working parallelly. May be > my understanding is wrong, can you please guide me > *sshdServer.setScheduledExecutorService(Executors.newScheduledThreadPool(5), > true);* > Will this spawn 5 parallel threads, and will be shut down gracefully as the > boolean is set to *true* > If it's a single thread model then if we use NioWorker threads as 2, and the > number of cores if I have 4 so total will be 6, so now as 1 core is occupied > with that single thread, will the remaining 5 cores will sit idle? -- 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-1132) Add support for SFTP "filename-charset" extension
[ https://issues.apache.org/jira/browse/SSHD-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1132 started by Lyor Goldstein. > Add support for SFTP "filename-charset" extension > - > > Key: SSHD-1132 > URL: https://issues.apache.org/jira/browse/SSHD-1132 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Minor > Labels: SFTP, sftp > > See https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-16 -- 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-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306873#comment-17306873
]
Lyor Goldstein commented on SSHD-1141:
--
{quote}
Too complicated IMO. No need for a session property, like the "current" key
this can just be a field in the UserAuthPublicKey object.
{quote}
Even better
{quote}
IMO also no need for a config property
{quote}
Not so sure - the reason {{ssh-rsa}} is being retired is because its use of
SHA-1 is no longer deemed secure enough. If we allow the above behavior by
default, we might be causing a security vulnerability where the client is
asking for a strong hash, but a malicious server somehow exploits some SHA-1
vulnerability and succeeds in forging a signature, thus convincing the client
to talk to it.
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1141) Implement server-sig-algs
[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306891#comment-17306891
]
Lyor Goldstein commented on SSHD-1141:
--
{quote}
It doesn't matter if the server returns a different algorithm (as long as it
returns the same key).
{quote}
And that it has used SHA-2... - I agree with your assessment...
> Implement server-sig-algs
> -
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Ian Wienand
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
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-1132) Add support for SFTP "filename-charset" extension
[ https://issues.apache.org/jira/browse/SSHD-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1132. -- Fix Version/s: 2.7.0 Resolution: Fixed > Add support for SFTP "filename-charset" extension > - > > Key: SSHD-1132 > URL: https://issues.apache.org/jira/browse/SSHD-1132 > Project: MINA SSHD > Issue Type: Improvement > Reporter: Lyor Goldstein >Assignee: Lyor Goldstein >Priority: Minor > Labels: SFTP, sftp > Fix For: 2.7.0 > > > See https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-16 -- 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-1150) Multiple hostkeys in single PEM
[
https://issues.apache.org/jira/browse/SSHD-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308941#comment-17308941
]
Lyor Goldstein commented on SSHD-1150:
--
{quote}
would like to use different hostkeys with different algorithms in a single PEM
hostkey file.
{quote}
Can you provide a sample PEM file that contains multiple keys ? Even better -
can you provide any documentation reference that describes this format in
detail ?
{quote}
Some SFTP server support this.
{quote}
Can you specify which servers support this ? Preferably some that can be easily
installed and tested...
> Multiple hostkeys in single PEM
> ---
>
> Key: SSHD-1150
> URL: https://issues.apache.org/jira/browse/SSHD-1150
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Stefan Mueller
>Priority: Major
>
> I would like to use different hostkeys with different algorithms in a single
> PEM hostkey file. Some SFTP server support this.
> Also the generator (like BouncyCastleGeneratorHostKeyProvider) could create a
> key for multiple algorithms.
--
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-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-1137 started by Lyor Goldstein. > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > Labels: AIX, aix > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false > leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, > which finally causes the opening to fail. > My assumption is that when setting the file attributes, the caller assumed > that "false" is a good choice as a default for a case when there is no > indication if links should be followed or not. But I would
[jira] [Commented] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[
https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17309882#comment-17309882
]
Lyor Goldstein commented on SSHD-1137:
--
{quote}
This fails equally on Windows, Linux or AIX for an initial open
{quote}
I have not been able to ascertain this - on my Windows machine (Windows 10)
there is no exception being thrown.
> IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH
> SFTP client
> -
>
> Key: SSHD-1137
> URL: https://issues.apache.org/jira/browse/SSHD-1137
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: SFTP-Server running on AIX
> OpenSSH SFTP client
>Reporter: Curd Reinert
>Assignee: Lyor Goldstein
>Priority: Minor
> Labels: AIX, aix
>
> When accessing an SFTP server running on AIX with an OpenSSH SFTP client
> (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well),
> I get the following exception:
> [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class:
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method:
> handleSetFileAttributeFailure Line: 2645 -
> /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread
> =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001,
> pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv]
> posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure
> details
> java.io.IOException: NOFOLLOW_LINKS is not supported on this platform
> at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272)
>
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541)
> at
> org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344)
> at
> de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> I've had a look into the source code. It seems the permissions requested by
> the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not
> supported by the file systems. This fails equally on Windows, Linux or AIX
> for an initial open, and therefore the catch block in [FileHandle (line
> 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75]
> is reached. Here the openFile for the channel is repeated without file
> attributes - succesfully - and then an attempt is made to set the file
> attributes with subsystem.doSetAttributes(file, attrs, false) - but this call
> needs that third argument for the follow link option, and setting it to false
> leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX,
> which finally causes the opening to fail.
> My assump
[jira] [Resolved] (SSHD-1150) Multiple hostkeys in single PEM
[
https://issues.apache.org/jira/browse/SSHD-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1150.
--
Assignee: Lyor Goldstein
Resolution: Won't Fix
{quote}
I suggest to close this issue.
{quote}
Agreed - the changes involved in adding this rather esoteric behavior do not
seem to justify the cost involved.
> Multiple hostkeys in single PEM
> ---
>
> Key: SSHD-1150
> URL: https://issues.apache.org/jira/browse/SSHD-1150
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Stefan Mueller
>Assignee: Lyor Goldstein
>Priority: Major
> Attachments: hostkeys.txt
>
>
> I would like to use different hostkeys with different algorithms in a single
> PEM hostkey file. Some SFTP server support this.
> Also the generator (like BouncyCastleGeneratorHostKeyProvider) could create a
> key for multiple algorithms.
--
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-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[
https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310130#comment-17310130
]
Lyor Goldstein commented on SSHD-1137:
--
Hi [~Curd Reinert], I have reviewed the code and I am not comfortable with
changing the {{false}} to {{true}} as you have suggested due to the possible
security consequences. However, I have added a mechanism that would enable
users (like yourself in this case) to decide whether they want to run this risk
or not. The {{SftpFileSystemAccessor}} has been fitted with a
{{resolveFileAccessLinkOptions}} method that is consulted for every SFTP
command (or extension) that requires {{LinkOption}}-s - including
{{SSH_FXP_OPEN}} that triggers the call flow you described. You can provide
your own {{SftpFileSystemAccessor}} that overrides this method's default
behavior when creating the {{SftpSubsystemFactory}} via its
{{withFileSystemAccessor}} method. This way you can either return an empty
{{LinkOption}}-s array globally or only for specific commands/extensions - up
to you - assuming of course responsibility for the possible security
consequences of following symlinks when you shouldn't.
> IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH
> SFTP client
> -
>
> Key: SSHD-1137
> URL: https://issues.apache.org/jira/browse/SSHD-1137
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.1
> Environment: SFTP-Server running on AIX
> OpenSSH SFTP client
>Reporter: Curd Reinert
>Assignee: Lyor Goldstein
>Priority: Minor
> Labels: AIX, aix
>
> When accessing an SFTP server running on AIX with an OpenSSH SFTP client
> (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well),
> I get the following exception:
> [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class:
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method:
> handleSetFileAttributeFailure Line: 2645 -
> /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread
> =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001,
> pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv]
> posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure
> details
> java.io.IOException: NOFOLLOW_LINKS is not supported on this platform
> at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242)
> at
> sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272)
>
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541)
> at
> org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344)
> at
> de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75)
> at
> org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377)
> at
> org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> I've had a look into the source code. It seems the permissions requested by
> the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not
>
[jira] [Resolved] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1137. -- Fix Version/s: 2.7.0 Resolution: Fixed > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > Labels: AIX, aix > Fix For: 2.7.0 > > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that third argument for the follow link option, and setting it to false > leads to using the "NOFOLLOW_LINK" option, and that is not supported on AIX, > which finally causes the opening to fail. > My assumption is that when setting the file attributes, the caller assumed > that "false" is a good choice as a default for a case when there is no > in
[jira] [Commented] (SSHD-1137) IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310236#comment-17310236 ] Lyor Goldstein commented on SSHD-1137: -- Hi [~Curd Reinert], I would appreciate it if you could run some tests with the modification and make sure it satisfies all your needs since the method I mentioned is consulted not only for opening files but for many other cases as well. It would help to know that it covers all these cases as well so as to avoid having to patch it once again after we release version 2.7.0 > IOException for unsupported NOFOLLOW_LINKS on AIX when accessing with OpenSSH > SFTP client > - > > Key: SSHD-1137 > URL: https://issues.apache.org/jira/browse/SSHD-1137 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 > Environment: SFTP-Server running on AIX > OpenSSH SFTP client >Reporter: Curd Reinert >Assignee: Lyor Goldstein >Priority: Minor > Labels: AIX, aix > Fix For: 2.7.0 > > > When accessing an SFTP server running on AIX with an OpenSSH SFTP client > (e.g. OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018, but other versions as well), > I get the following exception: > [DEBUG][sshd-TravicLinkSftpSubsystem-thread-1] 01.03.2021 10:00:31,019 Class: > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper Method: > handleSetFileAttributeFailure Line: 2645 - > /nhandleSetFileAttributeFailure(TravicLinkServerSession [Thread > =sshd-TravicLinkSftpSubsystem-thread-1, Mandant=DEKAFFM, Partner=DEALI001, > pause=false, Hashcode=1524776343])[/kati/kursanfo_in/enk1.csv] > posix:permissions=[OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] failure > details > java.io.IOException: NOFOLLOW_LINKS is not supported on this platform > at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:793) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setMode(UnixFileAttributeViews.java:242) > at > sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions(UnixFileAttributeViews.java:272) > > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFilePermissions(AbstractSftpSubsystemHelper.java:2793) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttribute(AbstractSftpSubsystemHelper.java:2672) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.setFileAttributes(AbstractSftpSubsystemHelper.java:2620) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doSetAttributes(AbstractSftpSubsystemHelper.java:2541) > at > org.apache.sshd.server.subsystem.sftp.FileHandle.(FileHandle.java:77) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doOpen(SftpSubsystem.java:911) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doOpen(AbstractSftpSubsystemHelper.java:532) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.doProcess(AbstractSftpSubsystemHelper.java:386) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.doProcess(SftpSubsystem.java:344) > at > de.ppi.fis.traviclink.transfer.transport.ftpserver.ssh.TravicLinkSftpSubsystem.doProcess(TravicLinkSftpSubsystem.java:75) > at > org.apache.sshd.server.subsystem.sftp.AbstractSftpSubsystemHelper.process(AbstractSftpSubsystemHelper.java:377) > at > org.apache.sshd.server.subsystem.sftp.SftpSubsystem.run(SftpSubsystem.java:317) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522) > at java.util.concurrent.FutureTask.run(FutureTask.java:277) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > I've had a look into the source code. It seems the permissions requested by > the client (OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ) are not > supported by the file systems. This fails equally on Windows, Linux or AIX > for an initial open, and therefore the catch block in [FileHandle (line > 75)|https://gitbox.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-sftp/src/main/java/org/apache/sshd/sftp/server/FileHandle.java;h=40c1056048f43184bc8aa589210dd18efb8130a7;hb=HEAD#l75] > is reached. Here the openFile for the channel is repeated without file > attributes - succesfully - and then an attempt is made to set the file > attributes with subsystem.doSetAttributes(file, attrs, false) - but this call > needs that
[jira] [Resolved] (SSHD-1151) How to check if NIO Worker Threads are getting set
[
https://issues.apache.org/jira/browse/SSHD-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1151.
--
Resolution: Information Provided
> How to check if NIO Worker Threads are getting set
> --
>
> Key: SSHD-1151
> URL: https://issues.apache.org/jira/browse/SSHD-1151
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Team,
> {code:java}
> public static final Property NIO_WORKERS
> = Property.validating(Property.integer("nio-workers",
> Runtime.getRuntime().availableProcessors() + 4),
> w -> ValidateUtils.checkTrue(w > 0, "Number of NIO workers must be positive:
> %d", w));{code}
> I have 4 processors and 4 extra threads, so total 8 NIO worker threads, but
> how will I confirm if it's actually getting set or not. Checked in the thread
> dumps but couldn't found anything related to NIO workers, not sure if its
> actually getting set. Need help and guidance.
--
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-1151) How to check if NIO Worker Threads are getting set
[
https://issues.apache.org/jira/browse/SSHD-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310237#comment-17310237
]
Lyor Goldstein commented on SSHD-1151:
--
Sorry, but I cannot think of an easy way to do this - you need to trust the
code - just look how this property is used. If you do want to spend some time
on it, then you can debug the code and place a breakpoint at the location where
this property is used and verify its behavior.
> How to check if NIO Worker Threads are getting set
> --
>
> Key: SSHD-1151
> URL: https://issues.apache.org/jira/browse/SSHD-1151
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Blocker
>
> Hello Team,
> {code:java}
> public static final Property NIO_WORKERS
> = Property.validating(Property.integer("nio-workers",
> Runtime.getRuntime().availableProcessors() + 4),
> w -> ValidateUtils.checkTrue(w > 0, "Number of NIO workers must be positive:
> %d", w));{code}
> I have 4 processors and 4 extra threads, so total 8 NIO worker threads, but
> how will I confirm if it's actually getting set or not. Checked in the thread
> dumps but couldn't found anything related to NIO workers, not sure if its
> actually getting set. Need help and guidance.
--
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-1153) NIO2 IOServiceFactory, NIO Worker Threads and the performance
[
https://issues.apache.org/jira/browse/SSHD-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311592#comment-17311592
]
Lyor Goldstein commented on SSHD-1153:
--
{quote}
decipher how the threads are working, and what does the thread dump means (in
the screenshot attached)
{quote}
Sorry, can't help you there - this is beyond my current expertise. I recommend
you post this question to d...@mina.apache.org.il and see if someone else can
help.
> NIO2 IOServiceFactory, NIO Worker Threads and the performance
> -
>
> Key: SSHD-1153
> URL: https://issues.apache.org/jira/browse/SSHD-1153
> Project: MINA SSHD
> Issue Type: Question
>Reporter: Susmit Sarkar
>Priority: Critical
> Attachments: image-2021-03-29-23-52-39-814.png,
> image-2021-03-29-23-54-01-301.png, image-2021-03-29-23-55-16-337.png,
> image-2021-03-29-23-55-33-299.png
>
>
> IoServiceFactoryFactory ==> *NIO2, MINA, NETTY*
> How does this works internally, and how performance will be affected with the
> different IoServiceFactoryFactory.
> We did lots of performance testing and found NIO2 is the best performing of
> the 3? Why is it the best of the other 2, and why Apache selects it as
> default.
> How does NIO Worker Threads affect the performance? Attaching a screenshot
> from the thread dump which I took
> !image-2021-03-29-23-52-39-814.png!
> All the threads in park state and some are runnable in different phases of
> execution. I am not able to decipher what does the stacks mean:
> The details which I got are (*PARKED*):
> !image-2021-03-29-23-54-01-301.png!
> For *RUNNABLE:*
> *!image-2021-03-29-23-55-33-299.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-1149) Allow every algorithm in PEM hostkey (old behaviour)
[
https://issues.apache.org/jira/browse/SSHD-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313216#comment-17313216
]
Lyor Goldstein commented on SSHD-1149:
--
{quote}
Can you change the behaviour back to where the specified algorithm was only
used to create new hostkeys?
{quote}
I don't think so - there are good reasons why we changed the behavior
{quote}
The old class loaded every hostkey, so we could change the algorithm used by
replacing the hostkey file.
{quote}
This is why we changed it.
{quote}
If the hostkey file contains a valid key, but not the algorithm set for server,
the file will be overwritten even with setOverwriteAllowed(false).
{quote}
I will look into it - anyway, these classes are not intended for runtime usage.
You are supposed to generate the host key file +externally+ and then use
{{KeyPairProvider}}-s for the server setup.
> Allow every algorithm in PEM hostkey (old behaviour)
>
>
> Key: SSHD-1149
> URL: https://issues.apache.org/jira/browse/SSHD-1149
> Project: MINA SSHD
> Issue Type: Wish
>Affects Versions: 2.3.0, 2.5.1
>Reporter: Stefan Mueller
>Priority: Major
>
> We upgraded SSHD and replaced PEMGeneratorHostKeyProvider with
> BouncyCastleGeneratorHostKeyProvider. Now we realized that the behaviour is
> different if the hostkey file exists. The old class loaded every hostkey, so
> we could change the algorithm used by replacing the hostkey file. Now the set
> algorithm will always be used.
> Can you change the behaviour back to where the specified algorithm was only
> used to create new hostkeys?
> In case you do not change it, I found a bug in current behaviour:
> If the hostkey file contains a valid key, but not the algorithm set for
> server, the file will be overwritten even with setOverwriteAllowed(false).
--
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-1144) type=SSH_FXP_CLOSE processing interrupted
[
https://issues.apache.org/jira/browse/SSHD-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313220#comment-17313220
]
Lyor Goldstein commented on SSHD-1144:
--
{quote}
when the disconnect (SSH_MSG_DISCONNECT) is received a "Thread.interrupt()" is
invoked on the service thread "sshd-SftpSubsystem-thread-x".
{quote}
I am not able to locate this claim in our code - can you show where it happens ?
{quote}
The service thread "sshd-SftpSubsystem-thread-x" then could be interrupted at
an unpredictable moment and this could cause a missed close of the file or
leaving the close-file processing in an inconsistent state (for example some
other resources not properly closed due to the "InterruptedException", etc.).
{quote}
I am not sure this true - the subsystem releases all resources when it is
destroyed.
> type=SSH_FXP_CLOSE processing interrupted
> -
>
> Key: SSHD-1144
> URL: https://issues.apache.org/jira/browse/SSHD-1144
> Project: MINA SSHD
> Issue Type: Bug
>Reporter: Ivan Fiorentini
>Priority: Major
>
> Some sftp clients (e.g. lftp) after a file-get they disconnect from the
> server without wait for the close-file (type=SSH_FXP_CLOSE processing)
> response.
> Here is an example of the "lftp get" exchange flow:
> {code:java}
> Running connect program (ssh -a -x -s -l user -p 22022 localhost sftp)
> ---> sending a packet, length=5, type=1(INIT), id=0
> <--- SPENG SFTP Server - Primeur
> user@localhost's password:
> <--- got a packet, length=576, type=2(VERSION), id=0
> protocol version set to 6
> ---> sending a packet, length=10, type=16(REALPATH), id=1
> <--- got a packet, length=33, type=104(NAME), id=1
> home set to /IVNQM1/LOCALE
> path on wire is `/IVNQM1/LOCALE/index.html'
> ---> sending a packet, length=47, type=3(OPEN), id=2
> <--- got a packet, length=41, type=102(HANDLE), id=2
> got file handle
> 6636636436393765363835616664643564333437396263386434386632303932 (32)
> ---> sending a packet, length=45, type=8(FSTAT), id=3
> <--- got a packet, length=64, type=105(ATTRS), id=3
> file info: size=612, date=Mon Mar 15 10:50:08 2021
> ---> sending a packet, length=53, type=5(READ), id=4
> ---> sending a packet, length=53, type=5(READ), id=5
> <--- got a packet, length=621, type=103(DATA), id=4
> data packet: pos=0, size=612
> ---> sending a packet, length=53, type=5(READ), id=6
> <--- got a packet, length=28, type=101(STATUS), id=5
> status code=1(EOF), message=End of file
> eof
> ---> sending a packet, length=41, type=4(CLOSE), id=7
> Disconnecting{code}
> On the server side, *using apache sshd 2.6.0*, the close-file processing
> (type=SSH_FXP_CLOSE processing) is delegated to the service thread
> "sshd-SftpSubsystem-thread-x" but when the disconnect (SSH_MSG_DISCONNECT) is
> received a "Thread.interrupt()" is invoked on the service thread
> "sshd-SftpSubsystem-thread-x".
> The service thread "sshd-SftpSubsystem-thread-x" then could be interrupted at
> an unpredictable moment and this could cause a missed close of the file or
> leaving the close-file processing in an inconsistent state (for example some
> other resources not properly closed due to the "InterruptedException", etc.).
> It seems there is no way to avoid the interrupt of the service thread
> "sshd-SftpSubsystem-thread-x" and/or wait the termination of the
> "type=SSH_FXP_CLOSE processing".
--
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-1116) Provide session context to the various XXXProvider(s)
[
https://issues.apache.org/jira/browse/SSHD-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1116:
Assignee: Lyor Goldstein
> Provide session context to the various XXXProvider(s)
> -
>
> Key: SSHD-1116
> URL: https://issues.apache.org/jira/browse/SSHD-1116
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Minor
>
> Similar to {{ClientIdentityProvider#getClientIdentities}}
> * {{PasswordIdentityProvider#loadPasswords}}
> * {{HostKeyIdentityProvider#loadHostKeys}}
> * add {{throws IOException, GeneralSecurityException}} clause where applicable
--
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-1106) SCP failed for target filename with space inside (and probably other special characters)
[ https://issues.apache.org/jira/browse/SSHD-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-1106. -- Resolution: Won't Fix > SCP failed for target filename with space inside (and probably other special > characters) > > > Key: SSHD-1106 > URL: https://issues.apache.org/jira/browse/SSHD-1106 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.5.1 >Reporter: min yun law >Assignee: Lyor Goldstein >Priority: Minor > Labels: deferred > > when using ScpClient.upload() and download() API and give the remote file > name with space inside, it will throw exception as: > java.io.EOFException: readAck - EOF before ACK > > Here is sample of code: > String localDir = "/scratch/downloads/"; > String fileName = "p201300_Linux-x86-64 (1).zip"; > String remotePath = "/tmp"; > File localPathFile = new File(localDir, fileName); > Path pathFile = localPathFile.toPath(); > //remote is linux > String remoteFullPath = remotePath+"/"+fileName; > Collection options = EnumSet.noneOf( > ScpClient.Option.class); > scpClient.upload(pathFile,remoteFullPath,option); //it will throw exception > > > -- 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-1136) Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on modulo size is not possible
[
https://issues.apache.org/jira/browse/SSHD-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1136 started by Lyor Goldstein.
> Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on
> modulo size is not possible
> --
>
> Key: SSHD-1136
> URL: https://issues.apache.org/jira/browse/SSHD-1136
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
> Assignee: Lyor Goldstein
>Priority: Major
>
> After implementation of SSHD-1107 we configured the minimum modulo size of
> diffie-hellman-group-exchange-sha256 to 2048 bit and expected clients that
> doesn't support this minimum to not be able to connect.
> But what happens is that, those clients still can connect and this warning is
> logged:
> {code}
> chooseDH(DHGEXServer[diffie-hellman-group-exchange-sha256])[ShaftServerSession[null@/10.42.110.99:44222]][prf=1024,
> min=1024, max=1024] No suitable primes found, defaulting to DHG1
> {code}
> My understanding is, that this is a fallback to diffie-hellman-group1-sha1
> which is week, see https://www.openssh.com/legacy.html
> Mina should make this fallback configurable and not activate it by default.
--
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-1136) Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on modulo size is not possible
[
https://issues.apache.org/jira/browse/SSHD-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1136.
--
Fix Version/s: 2.7.0
Resolution: Fixed
[~ahuegendp], Thanks for bringing this to our attention - fixed and will be
available on next release.
> Diffie Hellmann group exchange falls back to insecure DHG1 if agreement on
> modulo size is not possible
> --
>
> Key: SSHD-1136
> URL: https://issues.apache.org/jira/browse/SSHD-1136
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Achim Hügen
> Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.7.0
>
>
> After implementation of SSHD-1107 we configured the minimum modulo size of
> diffie-hellman-group-exchange-sha256 to 2048 bit and expected clients that
> doesn't support this minimum to not be able to connect.
> But what happens is that, those clients still can connect and this warning is
> logged:
> {code}
> chooseDH(DHGEXServer[diffie-hellman-group-exchange-sha256])[ShaftServerSession[null@/10.42.110.99:44222]][prf=1024,
> min=1024, max=1024] No suitable primes found, defaulting to DHG1
> {code}
> My understanding is, that this is a fallback to diffie-hellman-group1-sha1
> which is week, see https://www.openssh.com/legacy.html
> Mina should make this fallback configurable and not activate it by default.
--
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-1116) Provide session context to the various XXXProvider(s)
[
https://issues.apache.org/jira/browse/SSHD-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1116 started by Lyor Goldstein.
> Provide session context to the various XXXProvider(s)
> -
>
> Key: SSHD-1116
> URL: https://issues.apache.org/jira/browse/SSHD-1116
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Minor
>
> Similar to {{ClientIdentityProvider#getClientIdentities}}
> * {{PasswordIdentityProvider#loadPasswords}}
> * {{HostKeyIdentityProvider#loadHostKeys}}
> * add {{throws IOException, GeneralSecurityException}} clause where applicable
--
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-1116) Provide session context to the various XXXProvider(s)
[
https://issues.apache.org/jira/browse/SSHD-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1116:
-
Description:
Similar to {{ClientIdentityProvider#getClientIdentities}}
* {{PasswordIdentityProvider#loadPasswords}}
* {{HostKeyIdentityProvider#loadHostKeys}}
* {{AuthenticationIdentitiesProvider#loadIdentities}}
* add {{throws IOException, GeneralSecurityException}} clause where applicable
was:
Similar to {{ClientIdentityProvider#getClientIdentities}}
* {{PasswordIdentityProvider#loadPasswords}}
* {{HostKeyIdentityProvider#loadHostKeys}}
* add {{throws IOException, GeneralSecurityException}} clause where applicable
> Provide session context to the various XXXProvider(s)
> -
>
> Key: SSHD-1116
> URL: https://issues.apache.org/jira/browse/SSHD-1116
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Minor
>
> Similar to {{ClientIdentityProvider#getClientIdentities}}
> * {{PasswordIdentityProvider#loadPasswords}}
> * {{HostKeyIdentityProvider#loadHostKeys}}
> * {{AuthenticationIdentitiesProvider#loadIdentities}}
> * add {{throws IOException, GeneralSecurityException}} clause where applicable
--
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-1031) Async write: completion listener is not always invoked
[
https://issues.apache.org/jira/browse/SSHD-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein updated SSHD-1031:
-
Labels: user-confirmation-required (was: )
> Async write: completion listener is not always invoked
> --
>
> Key: SSHD-1031
> URL: https://issues.apache.org/jira/browse/SSHD-1031
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Evgeny Pasynkov
>Priority: Major
> Labels: user-confirmation-required
>
> Hi,
> Sometimes I observe the situation when the listener is not invoked for async
> write operation nor exception is thrown
> the code is:
> {noformat}
> try {
> val future = IoOutputStream.writePacket(...)
> future.addListener()
> } catch (...) {...}
> {noformat}
> When this occurs, the error is logged in ServerSession:
> {noformat}
> exceptionCaught(SSHServerSessionEx[])[state=Opened] IOException: Broken
> pipe
> {noformat}
> This problem never happened in 2.4.0
> Thank you in advance
--
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-1031) Async write: completion listener is not always invoked
[
https://issues.apache.org/jira/browse/SSHD-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313372#comment-17313372
]
Lyor Goldstein commented on SSHD-1031:
--
[~xvost] Is it still happening ? If no reply then I will close this issue
> Async write: completion listener is not always invoked
> --
>
> Key: SSHD-1031
> URL: https://issues.apache.org/jira/browse/SSHD-1031
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Evgeny Pasynkov
>Priority: Major
>
> Hi,
> Sometimes I observe the situation when the listener is not invoked for async
> write operation nor exception is thrown
> the code is:
> {noformat}
> try {
> val future = IoOutputStream.writePacket(...)
> future.addListener()
> } catch (...) {...}
> {noformat}
> When this occurs, the error is logged in ServerSession:
> {noformat}
> exceptionCaught(SSHServerSessionEx[])[state=Opened] IOException: Broken
> pipe
> {noformat}
> This problem never happened in 2.4.0
> Thank you in advance
--
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-1025) "java.net.SocketException: Too many open files" exception on long run of application with Apache Mina SSHD 2.1.0
[ https://issues.apache.org/jira/browse/SSHD-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313374#comment-17313374 ] Lyor Goldstein commented on SSHD-1025: -- [~BinayPaul0631] Is it still happening with version 2.6.0 ? If no reply received I will close this issue... > "java.net.SocketException: Too many open files" exception on long run of > application with Apache Mina SSHD 2.1.0 > > > Key: SSHD-1025 > URL: https://issues.apache.org/jira/browse/SSHD-1025 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: Oracle Linux 7 >Reporter: Binay Paul >Priority: Major > > This issue is observed during the performance testing of Oracle > Communications Sessions Delivery Manager (OCSDM) release 8.2.1 with Apache > Mina SSHD 2.1.0 version, after a long continuous run for about 15 to 16 hours > of OCSDM with processing REST/SOAP API calls in a 3 node cluster setup. > Root Cause Analysis: > When OCSDMis running continuously with REST/SOAP consecutive requests, list > of opened file descriptors count increases rapidly like some where around 23 > Lakh and this leads to an exception "java.net.SocketException: Too many open > files". > As a result of this DB read/write operations fails and OCSDM shutdown task is > triggered by the application. > The lsof command shows FD named "PIPE" and "EventPoll" are been opened by SDM > process in large number. > These FDs are opened by third party library Apache Mina which is used to make > SSH/SFTP connections to 297 devices which are present in SDM (Used for SDM > performance testing). > Walk around : As of now for OCSDM release 8.2.1 library Apache Mina is > replaced with JSCH 0.1.55 which is been used in previous versions of SDM and > application works as expected. > > Console.out : > [Wed Nov 13 23:49:36 EST 2019] WARNING: RMI TCP Accept-1099: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,localport=1099] throws > [Wed Nov 13 23:49:36 EST 2019] java.net.SocketException: Too many open files > [Wed Nov 13 23:49:36 EST 2019] at > java.net.PlainSocketImpl.socketAccept(Native Method) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.ServerSocket.implAccept(ServerSocket.java:545) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.ServerSocket.accept(ServerSocket.java:513) > [Wed Nov 13 23:49:36 EST 2019] at > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400) > [Wed Nov 13 23:49:36 EST 2019] at > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372) > [Wed Nov 13 23:49:36 EST 2019] at java.lang.Thread.run(Thread.java:745) > BEServer.log : > > 11/13 23:49:41.300 INFO [com.acmepacket.ems.server.main.BEServer] - Method: > [shutdown] Thread: [Thread-176494:334181] Msg:[# BEServer shutdown was > called # : Starting shutdown of BE server. ] > 11/13 23:49:41.300 INFO [com.acmepacket.ems.server.main.BEServer] - Method: > [shutDownApacheServer] Thread: [Thread-176494:334181] Msg:[# WebServer > shutdown was called # : Starting shutdown of http server] > 11/13 23:49:41.300 ERROR [com.acmepacket.ems.server.main.BEServer] - Method: > [shutDownApacheServer] Thread: [Thread-176494:334181] Msg:[Exception thrown > in attempting to shutdown Web server. Reason : Cannot run program > "../Apache/httpse > rver/bin/stopHttpServer.sh": error=24, Too many open files] > java.io.IOException: Cannot run program > "../Apache/httpserver/bin/stopHttpServer.sh": error=24, Too many open files > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:620) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:450) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:347) ~[?:1.8.0_74] > at > com.acmepacket.ems.server.main.BEServer.shutDownApacheServer(BEServer.java:989) > [ACMEPacketBEServer.jar:?] > at > com.acmepacket.ems.server.main.BEServer.shutdownWebServers(BEServer.java:954) > [ACMEPacketBEServer.jar:?] > at com.acmepacket.ems.server.main.BEServer.shutdown(BEServer.java:433) > [ACMEPacketBEServer.jar:?] > at com.acmepacket.ems.server.main.BEServer.shutdown(BEServer.java:403) > [ACMEPacketBEServer.jar:?] > at > com.acmepacket.ems.server.services.database.R
[jira] [Updated] (SSHD-1025) "java.net.SocketException: Too many open files" exception on long run of application with Apache Mina SSHD 2.1.0
[ https://issues.apache.org/jira/browse/SSHD-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1025: - Labels: user-response-required (was: ) > "java.net.SocketException: Too many open files" exception on long run of > application with Apache Mina SSHD 2.1.0 > > > Key: SSHD-1025 > URL: https://issues.apache.org/jira/browse/SSHD-1025 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: Oracle Linux 7 >Reporter: Binay Paul >Priority: Major > Labels: user-response-required > > This issue is observed during the performance testing of Oracle > Communications Sessions Delivery Manager (OCSDM) release 8.2.1 with Apache > Mina SSHD 2.1.0 version, after a long continuous run for about 15 to 16 hours > of OCSDM with processing REST/SOAP API calls in a 3 node cluster setup. > Root Cause Analysis: > When OCSDMis running continuously with REST/SOAP consecutive requests, list > of opened file descriptors count increases rapidly like some where around 23 > Lakh and this leads to an exception "java.net.SocketException: Too many open > files". > As a result of this DB read/write operations fails and OCSDM shutdown task is > triggered by the application. > The lsof command shows FD named "PIPE" and "EventPoll" are been opened by SDM > process in large number. > These FDs are opened by third party library Apache Mina which is used to make > SSH/SFTP connections to 297 devices which are present in SDM (Used for SDM > performance testing). > Walk around : As of now for OCSDM release 8.2.1 library Apache Mina is > replaced with JSCH 0.1.55 which is been used in previous versions of SDM and > application works as expected. > > Console.out : > [Wed Nov 13 23:49:36 EST 2019] WARNING: RMI TCP Accept-1099: accept loop for > ServerSocket[addr=0.0.0.0/0.0.0.0,localport=1099] throws > [Wed Nov 13 23:49:36 EST 2019] java.net.SocketException: Too many open files > [Wed Nov 13 23:49:36 EST 2019] at > java.net.PlainSocketImpl.socketAccept(Native Method) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.ServerSocket.implAccept(ServerSocket.java:545) > [Wed Nov 13 23:49:36 EST 2019] at > java.net.ServerSocket.accept(ServerSocket.java:513) > [Wed Nov 13 23:49:36 EST 2019] at > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400) > [Wed Nov 13 23:49:36 EST 2019] at > sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372) > [Wed Nov 13 23:49:36 EST 2019] at java.lang.Thread.run(Thread.java:745) > BEServer.log : > > 11/13 23:49:41.300 INFO [com.acmepacket.ems.server.main.BEServer] - Method: > [shutdown] Thread: [Thread-176494:334181] Msg:[# BEServer shutdown was > called # : Starting shutdown of BE server. ] > 11/13 23:49:41.300 INFO [com.acmepacket.ems.server.main.BEServer] - Method: > [shutDownApacheServer] Thread: [Thread-176494:334181] Msg:[# WebServer > shutdown was called # : Starting shutdown of http server] > 11/13 23:49:41.300 ERROR [com.acmepacket.ems.server.main.BEServer] - Method: > [shutDownApacheServer] Thread: [Thread-176494:334181] Msg:[Exception thrown > in attempting to shutdown Web server. Reason : Cannot run program > "../Apache/httpse > rver/bin/stopHttpServer.sh": error=24, Too many open files] > java.io.IOException: Cannot run program > "../Apache/httpserver/bin/stopHttpServer.sh": error=24, Too many open files > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:620) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:450) ~[?:1.8.0_74] > at java.lang.Runtime.exec(Runtime.java:347) ~[?:1.8.0_74] > at > com.acmepacket.ems.server.main.BEServer.shutDownApacheServer(BEServer.java:989) > [ACMEPacketBEServer.jar:?] > at > com.acmepacket.ems.server.main.BEServer.shutdownWebServers(BEServer.java:954) > [ACMEPacketBEServer.jar:?] > at com.acmepacket.ems.server.main.BEServer.shutdown(BEServer.java:433) > [ACMEPacketBEServer.jar:?] > at com.acmepacket.ems.server.main.BEServer.shutdown(BEServer.java:403) > [ACMEPacketBEServer.jar:?] > at > com.acmepacket.ems.server.services.database.ReplicatedXMLDatabaseManagerImpl.shutDownAfterFault(ReplicatedXMLDatabaseManagerImpl.java:2536) > [
[jira] [Closed] (SSHD-1011) Add support for channel count limit
[ https://issues.apache.org/jira/browse/SSHD-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1011. Resolution: Won't Fix > Add support for channel count limit > --- > > Key: SSHD-1011 > URL: https://issues.apache.org/jira/browse/SSHD-1011 > Project: MINA SSHD > Issue Type: New Feature >Reporter: Sandeep >Priority: Minor > > We have requirement where we need to set the maximum number of channels that > are allowed open at any one time. > You can see this property in mavericks named "setChannelLimit" and am unable > to find it in SSHD. > ref link is here: > [http://maverick-legacy-client-javadocs.s3-website-eu-west-1.amazonaws.com/com/maverick/ssh/SshContext.html] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1031) Async write: completion listener is not always invoked
[
https://issues.apache.org/jira/browse/SSHD-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein closed SSHD-1031.
Resolution: Fixed
> Async write: completion listener is not always invoked
> --
>
> Key: SSHD-1031
> URL: https://issues.apache.org/jira/browse/SSHD-1031
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Evgeny Pasynkov
>Priority: Major
> Labels: user-confirmation-required
>
> Hi,
> Sometimes I observe the situation when the listener is not invoked for async
> write operation nor exception is thrown
> the code is:
> {noformat}
> try {
> val future = IoOutputStream.writePacket(...)
> future.addListener()
> } catch (...) {...}
> {noformat}
> When this occurs, the error is logged in ServerSession:
> {noformat}
> exceptionCaught(SSHServerSessionEx[])[state=Opened] IOException: Broken
> pipe
> {noformat}
> This problem never happened in 2.4.0
> Thank you in advance
--
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-1116) Provide session context to the various XXXProvider(s)
[
https://issues.apache.org/jira/browse/SSHD-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1116.
--
Fix Version/s: 2.7.0
Resolution: Fixed
> Provide session context to the various XXXProvider(s)
> -
>
> Key: SSHD-1116
> URL: https://issues.apache.org/jira/browse/SSHD-1116
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
> Assignee: Lyor Goldstein
>Priority: Minor
> Fix For: 2.7.0
>
>
> Similar to {{ClientIdentityProvider#getClientIdentities}}
> * {{PasswordIdentityProvider#loadPasswords}}
> * {{HostKeyIdentityProvider#loadHostKeys}}
> * {{AuthenticationIdentitiesProvider#loadIdentities}}
> * add {{throws IOException, GeneralSecurityException}} clause where applicable
--
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-1149) Allow every algorithm in PEM hostkey (old behaviour)
[
https://issues.apache.org/jira/browse/SSHD-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313617#comment-17313617
]
Lyor Goldstein commented on SSHD-1149:
--
{quote}
If the hostkey file contains a valid key, but not the algorithm set for server,
the file will be overwritten even with setOverwriteAllowed(false).
{quote}
Not a bug - if the loaded file contains the wrong algorithm then it is
+deleted+ so when the code reaches:
{code:java}
protected void writeKeyPair(KeyPair kp, Path keyPath, OpenOption... options)
throws IOException, GeneralSecurityException {
if ((!Files.exists(keyPath)) || isOverwriteAllowed()) {
{code}
The {{Files.exists(keyPath)}} returns _false_ which means that a +new+ file is
generated.
> Allow every algorithm in PEM hostkey (old behaviour)
>
>
> Key: SSHD-1149
> URL: https://issues.apache.org/jira/browse/SSHD-1149
> Project: MINA SSHD
> Issue Type: Wish
>Affects Versions: 2.3.0, 2.5.1
>Reporter: Stefan Mueller
>Priority: Major
>
> We upgraded SSHD and replaced PEMGeneratorHostKeyProvider with
> BouncyCastleGeneratorHostKeyProvider. Now we realized that the behaviour is
> different if the hostkey file exists. The old class loaded every hostkey, so
> we could change the algorithm used by replacing the hostkey file. Now the set
> algorithm will always be used.
> Can you change the behaviour back to where the specified algorithm was only
> used to create new hostkeys?
> In case you do not change it, I found a bug in current behaviour:
> If the hostkey file contains a valid key, but not the algorithm set for
> server, the file will be overwritten even with setOverwriteAllowed(false).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1149) Allow every algorithm in PEM hostkey (old behaviour)
[ https://issues.apache.org/jira/browse/SSHD-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein closed SSHD-1149. Assignee: Lyor Goldstein Resolution: Won't Fix > Allow every algorithm in PEM hostkey (old behaviour) > > > Key: SSHD-1149 > URL: https://issues.apache.org/jira/browse/SSHD-1149 > Project: MINA SSHD > Issue Type: Wish >Affects Versions: 2.3.0, 2.5.1 >Reporter: Stefan Mueller > Assignee: Lyor Goldstein >Priority: Major > > We upgraded SSHD and replaced PEMGeneratorHostKeyProvider with > BouncyCastleGeneratorHostKeyProvider. Now we realized that the behaviour is > different if the hostkey file exists. The old class loaded every hostkey, so > we could change the algorithm used by replacing the hostkey file. Now the set > algorithm will always be used. > Can you change the behaviour back to where the specified algorithm was only > used to create new hostkeys? > In case you do not change it, I found a bug in current behaviour: > If the hostkey file contains a valid key, but not the algorithm set for > server, the file will be overwritten even with setOverwriteAllowed(false). -- 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-1118) Unable to connect with Fedora 33 which has dropped ssh-rsa from PubkeyAcceptedKeyTypes
[
https://issues.apache.org/jira/browse/SSHD-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1118.
--
Resolution: Information Provided
> Unable to connect with Fedora 33 which has dropped ssh-rsa from
> PubkeyAcceptedKeyTypes
> --
>
> Key: SSHD-1118
> URL: https://issues.apache.org/jira/browse/SSHD-1118
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Ian Wienand
>Priority: Major
>
> This problem was noted with Gerrit using a 2.4.0 mina sshd server [1] after a
> recent upgrade. Some users using Fedora 33 started being not able to log in.
> It turns out that Fedora >=33 has dropped rsa-ssh from it's default
> {{PubkeyAcceptedKeyTypes}} in
> {{/etc/crypto-policies/back-ends/openssh.config}}. You either have to modify
> your policy globally to "legacy" with "update-crypto-policies" or manually
> set {{PubkeyAcceptedKeyTypes=ssh-rsa}} for failing servers.
> I understand that {{server-sig-algs}} support isn't fully implemented in mina
> sshd as yet, so the client will not be seeing the negotiation list.
> However, it seems rsa-sha2-256/512 are supported? It seems like forcing this
> with {{ssh -oPubkeyAcceptedKeyTypes=rsa-sha2-512}} should work, but it does
> not (see related gerrit bug)?
> I can provide ssh connect logs, etc. if it will help; at this point I think
> it's mostly about understanding Fedora's change and any mina limitations so
> we can find the best solution for users. Although Fedora 33 users are
> obviously a small minority now, it probably flags something other distros
> will take up sooner or later.
>
> Thanks!
>
> [1] [https://bugs.chromium.org/p/gerrit/issues/detail?id=13930]
--
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-1083) The nio2 connector/acceptor implementation should not be tied to the FactoryManager
[
https://issues.apache.org/jira/browse/SSHD-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein reassigned SSHD-1083:
Assignee: Lyor Goldstein
> The nio2 connector/acceptor implementation should not be tied to the
> FactoryManager
> ---
>
> Key: SSHD-1083
> URL: https://issues.apache.org/jira/browse/SSHD-1083
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Guillaume Nodet
> Assignee: Lyor Goldstein
>Priority: Major
>
> It makes it difficult to use for very simple use cases such as in unit test,
> because this interface has a large amount of methods and is only implemented
> by SshClient and SshServer.
> A {{PropertyResolver}} should be sufficient. We may need to pass the
> {{IoServiceEventListener}} somehow, but it could be set at build time instead
> of using a getter/setter pair as it really never changes.
--
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-1083) The nio2 connector/acceptor implementation should not be tied to the FactoryManager
[
https://issues.apache.org/jira/browse/SSHD-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1083 started by Lyor Goldstein.
> The nio2 connector/acceptor implementation should not be tied to the
> FactoryManager
> ---
>
> Key: SSHD-1083
> URL: https://issues.apache.org/jira/browse/SSHD-1083
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Guillaume Nodet
> Assignee: Lyor Goldstein
>Priority: Major
>
> It makes it difficult to use for very simple use cases such as in unit test,
> because this interface has a large amount of methods and is only implemented
> by SshClient and SshServer.
> A {{PropertyResolver}} should be sufficient. We may need to pass the
> {{IoServiceEventListener}} somehow, but it could be set at build time instead
> of using a getter/setter pair as it really never changes.
--
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-1083) The nio2 connector/acceptor implementation should not be tied to the FactoryManager
[
https://issues.apache.org/jira/browse/SSHD-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lyor Goldstein resolved SSHD-1083.
--
Fix Version/s: 2.7.0
Resolution: Fixed
> The nio2 connector/acceptor implementation should not be tied to the
> FactoryManager
> ---
>
> Key: SSHD-1083
> URL: https://issues.apache.org/jira/browse/SSHD-1083
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Guillaume Nodet
> Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.7.0
>
>
> It makes it difficult to use for very simple use cases such as in unit test,
> because this interface has a large amount of methods and is only implemented
> by SshClient and SshServer.
> A {{PropertyResolver}} should be sufficient. We may need to pass the
> {{IoServiceEventListener}} somehow, but it could be set at build time instead
> of using a getter/setter pair as it really never changes.
--
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-1074) Too many SSH_MSG_CHANNEL_WINDOW_ADJUST requests were sent by Server
[ https://issues.apache.org/jira/browse/SSHD-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313680#comment-17313680 ] Lyor Goldstein commented on SSHD-1074: -- [~sreedharj] Is this still an issue ? If so, please specify the version you are using (make sure to try 2.6.0). If no response I will close this issue. > Too many SSH_MSG_CHANNEL_WINDOW_ADJUST requests were sent by Server > > > Key: SSHD-1074 > URL: https://issues.apache.org/jira/browse/SSHD-1074 > Project: MINA SSHD > Issue Type: Question >Reporter: Sreedhar J >Priority: Minor > > During the file transfer to Apache SFTP Server, I see lot of > SSH_MSG_CHANNEL_WINDOW_ADJUST requests are sent by Server to client. > > does it mean not enough buffers to handle? > > Here are the log entries > > 2020-09-02 21:54:28,946 [system-thread-1] DEBUG SftpSubsystem - > doSendStatus(ServerSessionImpl[admin@/10.84.41.27:60825])[id=1378] > SSH_FXP_STATUS (substatus=SSH_FX_OK, lang=, msg=) > 2020-09-02 21:54:28,946 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1431 sending > command=94[SSH_MSG_CHANNEL_DATA] len=30 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG ChannelSession - > sendWindowAdjust(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_WINDOW_ADJUST len=1050400 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1432 sending > command=93[SSH_MSG_CHANNEL_WINDOW_ADJUST] len=9 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG Window - Increase > Window[server/local](ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) by 1050400 up to > 2097152 > 2020-09-02 21:54:29,022 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > > 21:54:30,471 [system-thread-1] DEBUG SftpSubsystem - > doSendStatus(ServerSessionImpl[admin@/10.84.41.27:60825])[id=1410] > SSH_FXP_STATUS (substatus=SSH_FX_OK, lang=, msg=) > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1464 sending > command=94[SSH_MSG_CHANNEL_DATA] len=30 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ChannelSession - > sendWindowAdjust(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_WINDOW_ADJUST len=1050400 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1465 sending > command=93[SSH_MSG_CHANNEL_WINDOW_ADJUST] len=9 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG Window - Increase > Window[server/local](ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) by 1050400 up to > 2097152 > 2020-09-02 21:54:30,487 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > 2020-09-02 21:54:30,502 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > 2020-09-02 21:54:30,502 [system-thread-1] DEBUG SftpSubsystem - > process(ServerSessionImpl[admin@/10.84.41.27:60825])[length=32821, > type=SSH_FXP_WRITE, id=1411] processing > 2020-09- > -- 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-1074) Too many SSH_MSG_CHANNEL_WINDOW_ADJUST requests were sent by Server
[ https://issues.apache.org/jira/browse/SSHD-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein updated SSHD-1074: - Labels: user-confirmation-required user-response-required (was: ) > Too many SSH_MSG_CHANNEL_WINDOW_ADJUST requests were sent by Server > > > Key: SSHD-1074 > URL: https://issues.apache.org/jira/browse/SSHD-1074 > Project: MINA SSHD > Issue Type: Question >Reporter: Sreedhar J >Priority: Minor > Labels: user-confirmation-required, user-response-required > > During the file transfer to Apache SFTP Server, I see lot of > SSH_MSG_CHANNEL_WINDOW_ADJUST requests are sent by Server to client. > > does it mean not enough buffers to handle? > > Here are the log entries > > 2020-09-02 21:54:28,946 [system-thread-1] DEBUG SftpSubsystem - > doSendStatus(ServerSessionImpl[admin@/10.84.41.27:60825])[id=1378] > SSH_FXP_STATUS (substatus=SSH_FX_OK, lang=, msg=) > 2020-09-02 21:54:28,946 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1431 sending > command=94[SSH_MSG_CHANNEL_DATA] len=30 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG ChannelSession - > sendWindowAdjust(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_WINDOW_ADJUST len=1050400 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1432 sending > command=93[SSH_MSG_CHANNEL_WINDOW_ADJUST] len=9 > 2020-09-02 21:54:28,947 [system-thread-1] DEBUG Window - Increase > Window[server/local](ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) by 1050400 up to > 2097152 > 2020-09-02 21:54:29,022 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > > 21:54:30,471 [system-thread-1] DEBUG SftpSubsystem - > doSendStatus(ServerSessionImpl[admin@/10.84.41.27:60825])[id=1410] > SSH_FXP_STATUS (substatus=SSH_FX_OK, lang=, msg=) > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1464 sending > command=94[SSH_MSG_CHANNEL_DATA] len=30 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ChannelSession - > sendWindowAdjust(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_WINDOW_ADJUST len=1050400 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG ServerSessionImpl - > encode(ServerSessionImpl[admin@/10.84.41.27:60825]) packet #1465 sending > command=93[SSH_MSG_CHANNEL_WINDOW_ADJUST] len=9 > 2020-09-02 21:54:30,471 [system-thread-1] DEBUG Window - Increase > Window[server/local](ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) by 1050400 up to > 2097152 > 2020-09-02 21:54:30,487 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > 2020-09-02 21:54:30,502 [NioProcessor-2 ] DEBUG ChannelSession - > handleData(ChannelSession[id=0, > recipient=0]-ServerSessionImpl[admin@/10.84.41.27:60825]) > SSH_MSG_CHANNEL_DATA len=16384 > 2020-09-02 21:54:30,502 [system-thread-1] DEBUG SftpSubsystem - > process(ServerSessionImpl[admin@/10.84.41.27:60825])[length=32821, > type=SSH_FXP_WRITE, id=1411] processing > 2020-09- > -- 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
