[
https://issues.apache.org/jira/browse/SSHD-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286898#comment-17286898
]
Lyor Goldstein edited comment on SSHD-1127 at 2/19/21, 9:48 AM:
----------------------------------------------------------------
Please see
[https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#internal-exceptions-and-error-message-handling]
- this can give you and idea as to how you can use your own custom
{{SftpErrorStatusDataHandler}} and tap into the STDERR stream. As stated:
{quote}
the current code provides no built-in support for this feature
{quote}
Note though that since there is no standard as to what the STDERR data is you
are taking a big chance on the client not understanding what you are sending.
The fact that Maverick library +assumes+ that the data is a string is not
backed up AFAIK by any known documentation. The fact that it seems to work
seems like a stroke of luck rather than relying on standards.
{quote}
Data sent on stderr by the server SHOULD be considered free format debug or
supplemental error information, and MAY be displayed to the user.
{quote}
Note the phrase "+*free format*+"...
Our client code is set up to ignore it since there is no standard as to the
contents of the STDERR stream - however, you can also override it by providing
your own {{SftpClientFactory}} that returns a client derived from
{{DefaultSftpClient}} that overrides the {{createSftpChannelSubsystem}} and
provides an extension of the internal {{SftpChannelSubsystem}} that overrides
{{createErrOutputStream}} and returns your own stream.
was (Author: lgoldstein):
Please see
[https://github.com/apache/mina-sshd/blob/master/docs/sftp.md#internal-exceptions-and-error-message-handling]
- this can give you and idea as to how you can use your own custom
{{SftpErrorStatusDataHandler}} and tap into the STDERR stream. As stated:
{quote}
the current code provides no built-in support for this feature
{quote}
Note though that since there is no standard as to what the STDERR data is you
are taking a big chance on the client not understanding what you are sending.
The fact that Maverick library +assumes+ that the data is a string is not
backed up AFAIK by any known documentation. The fact that it seems to work
seems like a stroke of luck rather than relying on standards.
{quote}
Data sent on stderr by the server SHOULD be considered free format debug or
supplemental error information, and MAY be displayed to the user.
{quote}
Note the phrase "+*free format*+"...
Our client code is set up to ignore it since there is no standard as to the
contents of the STDERR stream - however, you can also override it by providing
your own {{SftpClientFactory}} that returns a client derived from
{{DefaultSftpClient}} that overrides the {{createSftpChannelSubsystem}} and
provides an extension of the internal {{SftpChannelSubsystem}} that overrides
{{createErrOutputStream}} and returns your own stream.
> SFTP/SCP SftpErrorStatusDataHandler is not propagating back proper custom
> messages to the client
> ------------------------------------------------------------------------------------------------
>
> Key: SSHD-1127
> URL: https://issues.apache.org/jira/browse/SSHD-1127
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Susmit Sarkar
> Priority: Minor
>
> Hi Team,
> *SftpErrorStatusDataHandler* is not propagating back proper custom messages
> to the client. Although it works fine with clients like FileZilla and WinSCP,
> we don't get a proper message for Unix-based SFTP command-line client.
> We can say that there is no issue with the implementation as it's working for
> clients like FileZilla and WinScp, so the code is fine. I agree with you on
> that.
> But commercial sftp server libraries are able to successfully propagate
> messages to all clients FileZilla, WinScp, Putty, Terminal.
> As for example, Maverick based SFTP server uses this API:
> {code:java}
> // code placeholder
> import com.maverick.sshd.SessionChannel;
> SessionChannel.sendStderrData("Too many concurrent logins. Please try again
> later.\n".getBytes("US-ASCII"));{code}
> [http://maverick-legacy-server-javadocs.s3-website-eu-west-1.amazonaws.com/com/maverick/sshd/SessionChannel.html#sendStderrData-byte:A-]
> I think a similar implementation should be introduced in the MINA library for
> future release.
> While reading the doc I came across this:
> ([https://github.com/apache/mina-sshd/blob/ac45b617272303058193db193650e7f2db3d1872/docs/sftp.md])
> If the registered handler implements {{ChannelSessionAware}} then it will
> also be informed of the registered {{ChannelSession}} when it is provided to
> the {{SftpSubsystem}} itself. This can be used to register an extended data
> writer that can handle data sent via the STDERR channel. *Note:* this feature
> is allowed according to [SFTP version 4 - section
> 3.1|https://tools.ietf.org/html/draft-ietf-secsh-filexfer-04#section-3.1]:
> Packets are sent and received on stdout and stdin. Data sent on stderr by the
> server SHOULD be considered debug or supplemental error information, and MAY
> be displayed to the user.
> *however, the current code provides no built-in support for this feature.*
> sftp> PUT docker-compose.yml
> debug3: Looking up docker-compose.yml
> Uploading docker-compose.yml to /dmicons/docker-compose.yml
> debug3: Sent message SSH2_FXP_OPEN I:8 P:/dmicons/docker-compose.yml
> remote open("/dmicons/docker-compose.yml"): Failure
> *---------------------------------------------------------------*
> Same operation in WinScp loggers are coming as:
> 2021-02-17 18:42:44.322 - Uploading a file to a full filesystem (HDD).
> * 2021-02-17 18:42:44.322 - Exceeding a user disk quota.
> . 2021-02-17 18:42:44.322 Asking user:
> . 2021-02-17 18:42:44.322 Cannot create remote file
> '/dmicons/IBM_UserTest.log'. ("General failure (server should provide error
> description).
> . 2021-02-17 18:42:44.322 Error code: 4
> . 2021-02-17 18:42:44.322 *Error message from server: User admin is not
> allowed to execute this SFTP command because of policy SFTP20*
> 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
