SFTP (x86/VMS) issues

[rodprince]

Issue #1 (cd)

On a VSI x86 VMS VM, if I do a $sftp 127.0.0.1 (loopback to the same VSI system). Once logged in:

1) cd rduser:[prince.temp]

response = realpath rduser:[prince.temp]: No such file

2) cd [.temp]

response = Can't change directory: "/DISK$B_VAXVMSV921/RDUSER/PRINCE/TEMP/[.temp]" is not a directory

3) cd temp (will work)

System Details:

VSI 9.2-1, 9.2-1X_UPDATE V1.0, OpenSSH V8.9-1F
Authorize default is "RDUSER:[PRINCE]"
RDUSER:[PRINCE.TEMP] does exist. Protection is O:RWED

Issue #2 (put)

From the VSI x86 VMS/VM, I can sftp to a HPE I64 system The "put" command will fail

put cmsrootdev.sav
response = Uploading cmsrootdev.sav to bnevad$dka0:[RDUSER.PRINCE]/cmsrootdev.sav
dest open "bnevad$dka0:[RDUSER.PRINCE]/cmsrootdev.sav": Failure

If I try and reverse the flow and log into the VSI system from the HPE system, the put will still fail, just a different error

put cmsrootdev.sav
response =
Warning: child process (/sys$system/tcpip$ssh_ssh2) exited with code 0.
%TCPIP-E-SSH_FC_ERROR, error in ssh file transfer operation

Interesting part here, is the file is created on the VSI side, with the same allocation as the HPE side (368592 blocks). Just nothing in the file.

Kind of odd that "get" works in either direction, but "put" will fail in either direction between HPE IA64/VMS and VSI x86/VMS

System Details:
HPE VMS 8.4, VMS84I_UPDATE V11.0, TCP V5.7-13ECO5
VSI 9.2-1, 9.2-1X_UPDATE V1.0, OpenSSH V8.9-1F

Rod

[sms]

Code: Select all

> 1) cd rduser:[prince.temp]

   If you tried "pwd", then you might get a hint as to what OpenSSH
expects for a path (device+directory spec).  Around here, for example:

v87 $ sftp v87
[...]
sftp> pwd
Remote working directory: /DISK$VMS0921V87/sms

sftp> cd /dka200/kits   # A (virtual) VMS installation disc
sftp> pwd
Remote working directory: /DISK$X860921OE/KITS

sftp> ls -l
drwxr-xr-x  var     1 65537    1             512 May 16 22:33 AVAIL_MAN_BASE_KIT
drwxr-xr-x  var     1 65537    1             512 May 16 22:32 DECNET_PHASE_IV_X8
60921_KIT
drwxr-xr-x  var     1 591722   9             512 May 16 23:04 DECNET_PLUS
drwxr-xr-x  var     1 591722   9             512 May 16 23:04 DWMOTIF
drwxr-xr-x  var     1 65537    1             512 May 16 22:32 DWMOTIF_SUPPORT_X8
60921_KIT
drwxr-xr-x  var     1 591722   9             512 May 16 22:57 KERBEROS
drwxr-xr-x  var     1 591722   9             512 May 16 23:03 OPENSSH
drwxr-xr-x  var     1 591722   9             512 May 16 23:04 PERL534
drwxr-xr-x  var     1 591722   9             512 May 16 23:01 SSL111
drwxr-xr-x  var     1 591722   9             512 May 16 22:57 SSL3
drwxr-xr-x  var     1 591722   9             512 May 16 22:57 TCPIP

sftp> 


   I'm not entirely thrilled by the substitution of the logical name for
the device, but it does work.

   One might argue that OpenSSH on VMS should accept VMS-native file
specs, but it wouldn't be my top priority.


> HPE VMS 8.4, VMS84I_UPDATE V11.0, TCP V5.7-13ECO5

   I don't remember the details.  Didn't TCPIP use some lame
SCP-based implementation for its "SFTP"?  As I recall, TCPIP "SFTP" had
trouble with many (real) SFTP implementations.  I'd try an SFTP
interaction between a non-VMS system and the OpenSSH SFTP on the x86_64
VMS system.  I wouldn't hold my breath waiting for TCPIP "SFTP" to be
improved.

   There's still something to be said in favor of DECnet for VMS-VMS
file transfers, I claim.