[ 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