[
https://issues.apache.org/jira/browse/SSHD-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872566#comment-16872566
]
Goldstein Lyor edited comment on SSHD-927 at 6/25/19 5:47 PM:
--------------------------------------------------------------
I think I do see a problem:
{noformat}
14:42:08.130 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
process(ServerSessionImpl[test@/127.0.0.1:62996])[length=91,
type=SSH_FXP_EXTENDED, id=5] processing
14:42:08.131 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
executeExtendedCommand(ServerSessionImpl[test@/127.0.0.1:62996]) received
unsupported SSH_FXP_EXTENDED(file-content-has...@ssh.com)
14:42:08.132 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
doSendStatus(ServerSessionImpl[test@/127.0.0.1:62996])[id=5] SSH_FXP_STATUS
(substatus=SSH_FX_OP_UNSUPPORTED, lang=, msg=Command
SSH_FXP_EXTENDED(file-content-has...@ssh.com) is unsupported or not implemented)
{noformat}
The client sends an unsupported extended opcode
({{(file-content-has...@ssh.com}}) - SSHD behaves according to the standard:
{quote}If the server does not recognize the 'extended-request' name, then the
server MUST respond with SSH_FXP_STATUS with error/status set to
SSH_FX_OP_UNSUPPORTED.
{quote}
it seems that the client takes it badly and decides to close the connection.
According to the standard, the client should use the {{"supported2"}} packet to
query what extensions are supported and not send unsupported ones. Therefore,
at least the way I read this, the client is not adhering to the SFTP standard.
was (Author: lgoldstein):
I think I do see a problem:
{noformat}
14:42:08.130 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
process(ServerSessionImpl[test@/127.0.0.1:62996])[length=91,
type=SSH_FXP_EXTENDED, id=5] processing
14:42:08.131 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
executeExtendedCommand(ServerSessionImpl[test@/127.0.0.1:62996]) received
unsupported SSH_FXP_EXTENDED(file-content-has...@ssh.com)
14:42:08.132 [sshd-SftpSubsystem-thread-1] DEBUG
o.a.s.s.subsystem.sftp.SftpSubsystem -
doSendStatus(ServerSessionImpl[test@/127.0.0.1:62996])[id=5] SSH_FXP_STATUS
(substatus=SSH_FX_OP_UNSUPPORTED, lang=, msg=Command
SSH_FXP_EXTENDED(file-content-has...@ssh.com) is unsupported or not implemented)
{noformat}
The client sends an unsupported extended opcode
({{(file-content-has...@ssh.com}}) - SSHD behaves according to the standard:
{quote}
If the server does not recognize the 'extended-request' name, then the server
MUST respond with SSH_FXP_STATUS with error/status set to SSH_FX_OP_UNSUPPORTED.
{quote}
it seems that the client takes it badly and decides to close the connection.
> SFTP put fails terminating the connection if the remote file exists
> -------------------------------------------------------------------
>
> Key: SSHD-927
> URL: https://issues.apache.org/jira/browse/SSHD-927
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.1.0, 2.2.0
> Environment: Java:
> C:\Program Files\Java\jdk1.8.0_201\bin>java -version
> java version "1.8.0_201"
> Java(TM) SE Runtime Environment (build 1.8.0_201-b26)
> Java HotSpot(TM) 64-Bit Server VM (build 25.201-b26, mixed mode)
> Apache SSHD : 2.1.0
> C:\temp>sftp2 --version
> sftp2: Tectia Client 6.4.14 on x86-pc-windows
> Build: 26
> Product: Tectia Client
> License type: commercial
> Copyright (C) SSH Communications Security Corporation.
> This software is protected by international copyright laws.
> All rights reserved.
> This product includes software developed by the OpenSSL Project
> for use in the OpenSSL Toolkit. (http://www.openssl.org/)
> SFT API: 2.0.3 (build 6.4.14.26)
> Reporter: Logan
> Priority: Major
> Attachments: sshd.log, thread-callstack.txt
>
>
> Sftp put fails if the file already exists on the sftp server, terminating the
> sfp session immediately.Below is the simple configuration to reproduce
>
> {code:java}
> SshServer sshd = SshServer.setUpDefaultServer();
> sshd.setPort(9999);
> sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider());
> sshd.setSubsystemFactories(Arrays.asList(new SftpSubsystemFactory()));
> sshd.setFileSystemFactory(new VirtualFileSystemFactory(new
> File("C:/temp").toPath()));
> sshd.setPasswordAuthenticator(AcceptAllPasswordAuthenticator.INSTANCE);
> sshd.start();
> {code}
>
> {noformat}
> C:\temp>sftp2 test@localhost#9999
> Host key for the host "localhost#9999" not found from database.
> The fingerprint of the host public key is:
> Babble: "xodec-damen-ripeg-hehuh-venep-pebys-zureg-rynit-mypiz-byheh-zixax"
> RFC4716: "1d:4f:c2:a4:fe:58:93:61:fe:44:69:26:f2:41:34:f7"
> You can get a public key's fingerprint by running
> % ssh-keygen-g3 -F publickey.pub
> on the key file.
> Please select how you want to proceed.
> cancel) Cancel the connection.
> once) Proceed with the connection but do not save the key.
> save) Proceed with the connection and save the key for future use.
> Please select one (cancel, once, save): once
> test@localhost#9999's password:
> Remote system type is POSIX.
> sftp> put ndp46-kb4483451-x64_41ba9b8a814351a318e78e4e1c02adc7e9fff67a.exe
> Error: Connection lost.
> {noformat}
> Upon Debugging I found the SftpSystem is terminated because the file channel
> received close command ( see attached )
> Added event listener to see reading and read method are called but no
> writing/write methods are never called.
>
> This can reproducible with v2.2.0
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
