SFTP - PUT makes a zero length file

[Steve-Thompson]

Good day Forum

I have set up and tested SFTP between 2 Alpha-OpenVMS servers and its working interactivley and in batch.

Now I want to PUT files onto a third party unix system. The result is a zero length file but with the correct file name and location.

I can "rm" these empty files within an interactive SFTP session, so I'm inclined to think the problem is my end (OpenVMS).

I'm doing tests interactivly with password login, ie I'm not using a key for the moment.

Some backgound:-

TCPIP> sho ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a AlphaServer 1000A 5/400 running OpenVMS V7.3-2
----------------------
What happens....

sftp> ls
.
SSH2
folderMonitor
incoming
ssh2
sftp> cd incoming
/incoming
sftp> debug 3
sftp> put test.dat
SshFCGlob/SSHFC_GLOB.C:803: Adding file test.dat to file list without globbing...
SshFCGlob/SSHFC_GLOB.C:649: File list is at its end.
SshFCGlob/SSHFC_GLOB.C:980: Destroying global data...
SshFCRecurse/SSHFC_RECURSE.C:398: File is "raw", and it needs to be parsed.
Ssh2SftpServer/SSHFILEXFERS.C:3196: Received SSH_FXP_STAT
Ssh2SftpServer/SSHFILEXFERS.C:3269: SSH_FXP_STAT test.dat
Ssh2SftpServer/SSHFILEXFERS.C:3271: Statting file `test.dat'
Ssh2SftpServer/SSHFILEXFERS.C:3406: rfm=FAB$C_STMLF
Ssh2SftpServer/SSHFILEXFERS.C:3509: attrs->size=480
SshFCRecurse/SSHFC_RECURSE.C:568: File test.dat is not a directory. Adding it to list...
SshFCRecurse/SSHFC_RECURSE.C:737: No more files in this list.
SshFCTransfer/SSHFC_TRANSFER.C:2463: File list has 2 files.
SshFCTransfer/SSHFC_TRANSFER.C:355: Setting next source file item...
SshFCTransfer/SSHFC_TRANSFER.C:561: Next source file is /test.dat .
SshFCTransfer/SSHFC_TRANSFER.C:1283: Statting source file test.dat...
Ssh2SftpServer/SSHFILEXFERS.C:3196: Received SSH_FXP_STAT
Ssh2SftpServer/SSHFILEXFERS.C:3269: SSH_FXP_STAT test.dat
Ssh2SftpServer/SSHFILEXFERS.C:3271: Statting file `test.dat'
Ssh2SftpServer/SSHFILEXFERS.C:3406: rfm=FAB$C_STMLF
Ssh2SftpServer/SSHFILEXFERS.C:3509: attrs->size=480
SshFCTransfer/SSHFC_TRANSFER.C:1432: Statting destination file incoming/. before trying to remove it...
SshFCTransfer/SSHFC_TRANSFER.C:1654: Statting destination file to check len incoming/./test.dat...
Ssh2SftpServer/SSHFILEXFERS.C:2240: Received SSH_FXP_OPEN
Ssh2SftpServer/SSHFILEXFERS.C:2318: SSH_FXP_OPEN test.dat
Ssh2SftpServer/SSHFILEXFERS.C:2334: Downloading `test.dat'
Ssh2SftpServer/SSHFILEXFERS.C:2402: rfm=FAB$C_STMLF
SshFCTransfer/SSHFC_TRANSFER.C:1456: Statting destination file incoming/./test.dat...
SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
FATAL: BUILD13$:[TCPIP_V54_BLECO7.SRC.SSH2]SSHFC_TRANSFER.C;1:1835 SshFCTransfer (function name unavailable) Assertion failed: tdat4


%TCPIP-F-SSH_FATAL, non-specific fatal error condition
system@vigia2>

[Richard Whalen]

I think that it's a program error, not a user error. The SFTP server on the Unix system is returning something unexpected, or not returning something that is expected, and this is causing a problem for the SFTP client.

[Steven Schweda]

Are you offering any hints as to what,
exactly, is running on that "third party
unix system"? (Or do you believe that if
you've seen one UNIX, you've seen them all?)

Around here, with a Solaris system:

[...]
Ssh2SftpServer/SSHFILEXFERS.C:2240: Received SSH_FXP_OPEN
Ssh2SftpServer/SSHFILEXFERS.C:2318: SSH_FXP_OPEN fred.dat
Ssh2SftpServer/SSHFILEXFERS.C:2334: Downloading `fred.dat'
Ssh2SftpServer/SSHFILEXFERS.C:2402: rfm=FAB$C_STMLF
SshFCTransfer/SSHFC_TRANSFER.C:1456: Statting destination file ./fred.dat...

debug(23-AUG-2008 22:44:06.49): Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug(23-AUG-2008 22:44:06.50): Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 94 to connection
debug(23-AUG-2008 22:44:06.50): Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug(23-AUG-2008 22:44:06.50): Ssh2Transport/TRCOMMON.C:1105: Sending packet wiSshFCTransferCore/SSHFC_TRCORE.C:357: Starting transfer for file fred.dat, destination ./fred.dat

debug(23-AUG-2008 22:44:06.50): Ssh2Transport/TRCOMMON.C:1105: Sending packet with type 2 to connection
debug(23-AUG-2008 22:44:06.50): Ssh2Transport/TRCOMMON.C:1105: Sending packet wifred.dat | 34B | 0.0 kB/s | TOC: 00:00:01 | 100%
SshFCTransferCore/SSHFC_TRCORE.C:851: Writer finished.
SshFCTransfer/SSHFC_TRANSFER.C:1943: Destination file attributes not available or that file is not a regular file; not changing attributes.
SshFCTransfer/SSHFC_TRANSFER.C:1972: Closing source file fred.dat...
SshFCTransfer/SSHFC_TRANSFER.C:1989: Closing dest file ./fred.dat...
SshFCTransfer/SSHFC_TRANSFER.C:2036: Finished with file ./fred.dat.
SshFCTransfer/SSHFC_TRANSFER.C:355: Setting next source file item...
SshFCTransfer/SSHFC_TRANSFER.C:375: No more source files in this list.
Ssh2SftpServer/SSHFILEXFERS.C:2909: Received SSH_FXP_CLOSE
Ssh2SftpServer/SSHFILEXFERS.C:2911: SSH_FXP_CLOSE
Ssh2SftpServer/SSHFILEXFERS.C:3013: Closed file `fred.dat' (handle=53a68d)
[...]


ra# uname -a
SunOS ra 5.10 Generic_127127-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

ra# /usr/lib/ssh/sshd -xxx
sshd: illegal option -- x
sshd version Sun_SSH_1.1
[...]

alp $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

alp $ ssh "-V"
alp$dka0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (
V5.5) 3.2.0 on COMPAQ Professional Workstation - VMS V7.3-2



> sftp> cd incoming

Practically every plain FTP attack I've ever
seen looks for a writable directory named
"incoming". SFTP may be safer, but I'd avoid
that name on any system I managed.

[Thomas Ritter]

How about showing the results of

$ sftp -V you@remote_host

We had similar problems SFTPing from UCX VMS to Multinet VMS and had to limit the negotiated protocol version to 3 using a logical name.

On the server side ...
$ define multinet_sftp_maximum_protocol_version 3

My 2 cents.

[Richard Whalen]

MultiNet's SFTP client & server have the ability to limit the version negotiated because there are occasional problems with operating at protocol version 4 with certain implementations and set ups. There is a version of the TCP/IP services client that says it supports protocol version 999 when it sends the initialization message, but it really only supports version 3. Usually it runs into an error while parsing a status message, but I suppose that it's possible that it might get as far as opening a file for write before it runs into an error.

[Steve-Thompson]

Good morning all

I've just returned to my desk, having had a short break 1000 or so Kms from the office.

In this time the end client who has been reluctant to give any useful information on their SFTP implementation (obviously due to its sensitive nature), has informed me that it is incompatible with SFTP/SCP under VMS.

So I will thank everyone for their interest
with a few points.

[Steve-Thompson]

.