3rd party SFTP Client and OpenVMS Server CWD problem

[otad21]

Hello,

I am using a 3rd party SFTP client and connecting to OpenVMS  (SSH Banner is [SSH-2.0-3.2.0 SSH OpenVMS V5.5 VMS_sftp_version 3])

Say my default home dir is DISKA:[DIR123]

When I PWD, from the SFTP client, I get

/diska/000000/dir123

I can CWD to /DISKA/DIR123/SUBDIROF123

and it works OK.

Now if I want to go to another directory on DISKB for example,

CWD /diskb/DIR456

fials.

I can view interact with files on the default disk but when I CWD to a directory on another disk, I get a No Such Path error.

(The client ahs a verbose trace option and it indicates SFTP status = 2).

If open ans SSH console connection I can

SET DEFAULT   DISKB:[DIR456]

and SHOW DEFAULT confirms that it succeeded.

I tried the SFTP client with other servers (Unix) and it has no problem chaning directories.

I use the same credentials to login to the SFTP and SSH consol sessions.

[Steven Schweda]

> I am using a 3rd party SFTP client [...]

   Not a very detailed description of anything.

> [...] (SSH Banner is [...]

   _Which_ banner?

   As usual, showing actual commands with their actual output can be
more helpful than vague descriptions or interpretations.  For example:

      tcpip show version
      ssh "-V"

> When I PWD, from the SFTP client, I get
>
> /diska/000000/dir123

   Around here, I get nothing like that:

alp $ sftp alp-l

@ SYS$MANAGER:ANNOUNCE.TXT
sftp> pwd
ALP$DKC0:[SMS]

> I can CWD [...]

   That's an actual command?

   I don't know what your software is.  I don't know what you're doing
with it.  I don't know what happens when you do it.  These things make
it hard to be helpful.

[otad21]

Hello Steven,

Thanks for your reply.  I will try to be more specific.

The 3rd party software is an FTP-like command-line interface to SFTP protocol written by a friend.  It runs from a Windows command prompt.

I asked and these are the answers:

1. The SSH Banner is actually the banner returned from the SSH server to the SSH client after connecting the TCP socket as per SSH RFC.  This is how the client identifies that the application it just connected to is capable of negotiating SSH.

2. The PWD command is handled by the client as sending an SSH_FXP_REALPATH with path argument "."

e.g.:

>PWD

>257 "/diska/000000/dir123" is the current directory.

3. In response to the REALPATH SFTP command, the server replies with an  SSH_FXP_NAME response. This response speicfies "/diska/000000/dir123".

i.e. this unix-like path is the actual SFTP server's response (running on OpenVMS)

4. The CWD command is handled by sending an SSH_FXP_OPENDIR SFTP request with the path argument supplied by the user converted to a unix-like syntax.

i.e. "CWD DISKA:[DIR123.SUBDIROF123] is traanslated as follows:

a- The "DISKA:[DIR123.SUBDIROF123]" argument is converted into "/DISKA/DIR123/000000/SUBDIROF123" and

b- this Unix path is supplied as the parameter to the SSH_FXP_OPENDIR command

c- the SFTP command is sent to the server.

d- The server accepts this path and returns a proper SFTP handle.  Which the client can use to issue SSH_FXP_READDIR commands to retrieve the listing.

e.g.

>CWD DISKA:[DIR123.SUBDIROF123]

>250 CWD command successful.

>LS

> ...  listing of files in SUBDIROF123.....

The problem is when the desired path is on a different disk than the user's default one (i.e DISKB).

The SFTP server returnes a SSH_FXP_STATUS reply and the reply code is SSH_FX_NO_SUCH_FILE instead of an SFTP handle.

>CWD DISKB:[DIR456]

>550 "/diskb/000000/dir456" is an invalid path.

Directory DISKB:[DIR456] does exist and I can SET DEFAULT on it and list its content from a console session.

I hope the details and examples above help clarify my problem.

Thanks...

[Hoff]

In all seriousness, what leads you to believe that the error is with VMS or with the TCP/IP Services client?

This configuration prominently features a (one-off?) client from "A Friend", connecting to an ssh and sftp server package that has seen more than a little use over the years.  While neither OpenVMS nor TCP/IP Services are free from bugs, none of us have encountered this "A Friend" sftp client that's a key component here.

Put another way, Occam's Razor points in another direction entirely; that there are issues with the sftp client and its compatibility.

Contact the "A Friend" software support organization, and request escalation assistance with the sftp client.

Alternatively (and given you're here, a reader can easily infer that the "A Friend" software support for this sftp client might be somewhat lacking), configure and use the PuTTY package and its command-line tools, and use this to determine if the error is within the "A Friend" software, or within OpenVMS or the TCP/IP Services ssh and sftp server components.

[otad21]

The Firend represents a major software developer and provided me with a copy of their software to test.  At this point, I am not at liberty to disclose the names for some stupid contractual restrictions.

Having said that, what I went to great lengths to describe shows, that the SFTP client can sucessfully handle the OpenVMS SFTP server implementation.

It can successfully issue SFTP commands that list and transfer fiels from and to OpenVMS directories.  My "Contact" (since the word "Friend" seems to blind you from the real issue here) maintains that  organizations successfully deployed and used their software and they had never reported such a problem. 

Their Technical Support produced SFTP traces demonstrating that the only difference between the successful and failed CWD commands was that the successful targeted a directory under the same default disk while the failed one targeted a directory on a different disk.

Thanks for the PuTTy suggestion.  I tried it and it behaves the same. 

If this is the wrong forum to ask this question, please guide me to the correct one.

[Hoff]

The "correct" forum is the forum that is supporting this (still unspecified) sftp software client.

Please provide the full command sequence, exactly as input, and the identity of the Windows client.

What's this "cwd" command do in this particular sftp client?

On the local sftp clients, the command to change directories is usually "cd".

Again, please discuss this with whomever is supporting this sftp client.   (Your ssh example only indicates that you appear to have the necessary permissions when logged into OpenVMS, and not whether the sftp client is functional, nor that the sftp syntax here is correct.)

[Steven Schweda]

> The 3rd party software is [...]

   Ok.

> 2. The PWD command is handled by the client as sending an
> SSH_FXP_REALPATH with path argument "." [...]

   Ok.  Unlike with a typical FTP client+server system where a "quote"
command at the client can be used to send an arbitrary command to the
server, I know of no way to play around this way using a typical SFTP
client.  So, without writing an SFTP client (or modifying an existing
one), I don't see an easy way to investigate this situation.

   But, someone else may know more than I.

> >257 "/diska/000000/dir123" is the current directory.

   What is the VMS SYS$LOGIN spec for this account?  DISKA:[DIR123] or
DISKA:[000000.DIR123]?  If the SFTP server is adding the "000000" stuff,
then I'd probably call it a bug in the server.

> 4. The CWD command is handled by sending an SSH_FXP_OPENDIR SFTP
> request with the path argument supplied by the user converted to a
> unix-like syntax.
>
> i.e. "CWD DISKA:[DIR123.SUBDIROF123] is traanslated as follows:
>
> a- The "DISKA:[DIR123.SUBDIROF123]" argument is converted into
> "/DISKA/DIR123/000000/SUBDIROF123" and [...]

   On the other hand, if the friend-written SFTP client program is
adding the "000000" stuff, then I'd probably call it a bug in the
client.

[otad21]

Thank Hoff you for your reply.

I already went to the SFTP client support and they maintain that their client has been tested thoroughly against a multitude of SFTP servers.

The entire sequence of commands has already been presented I will post here again:

(client's interface accepts cwd and cd for chagne directory, <enter> designates where I press the ENTR key)

C:\sftp2<enter>

>open MYSERVERNAME<enter>

>Welcome to XYZ SFTP client. pending connection to MYSERVERNAME. 

>user MYUSERNAME<enter>

>331 Password required for user MYUSERNAME

>password ********<enter>

>230 User MYUSERNAME logged in OK.

>pwd<enter>

>257 "/diska/000000/dir123" is the current directory.

>ls<enter>

> ... listing the contents of directory DIR123

>cd DISKA:[DIR123.SUBDIROF123]<enter>

>250 CWD command successful.

>ls<enter>

> ...  listing of files in SUBDIROF123.....

>cd  DISKB:[DIR456]<enter>

>550 "/diskb/000000/dir456" is an invalid path.

I have already explained what SFTP requests each of the above command line requets translated to.

Also, int the above sequence, the listing generated after the ls command are correct.  If I use PUT or GET or MPUT or MGET commands to upload/download a single/multiple files, the transfer succeeds.

So lets not get hung on this client, it works just fine.  Whether it uses CD or CWD or CHDIR is irrelevant.  What is relevant is that what goes on the wire after I hit enter is a correct SFTP request.

I already reported that PuTTY behaves in exactly the same way.  So it is not a problem unique to this particular SFTP client.  Furhter, the vendor is ready to supply SFTP trace fragments to prove that their SFTP syntax is correct.

Please excuse the following shouting, no disrespect intended, but I feel I need to press the actual point: 

The problem is that the SFTP server on the OpenVMS system DOES NOT SEE A DIRECTORY THAT CAN BE SEEN FROM A CONSOLE CONNECTION, for the same logged-in user.

In response to SSH_FXP_REALPATH SFTP request that specifies "/DISKA/000000/DIR123/SUBDIROF123", the server returns a valid SFTP handle reply.

In response to SSH_FXP_REALPATH SFTP request that specifies "/DISKB/000000/DIR456", the server returns an SSH_FXP_STATUS with staus code SSH_FX_NO_SUCH_FILE

The two SFTP requests are syntactically identical.  The only difference between the two is the target directory.

Maybe it would help if I re-phrase the question: 

How do you CD to a directory on a disk different than your default disk when using SFTP command line client to access an SFTP server on OpenVMS...... 

[otad21]

Thanks for Steven your reply.

re: "What is the VMS SYS$LOGIN spec for this account?  DISKA:[DIR123]..etc.."  unfortunately, I am just a simple VMS user who needs SFTP access to some files on the server.

re: "If the SFTP server is adding the "000000" stuff," I am not sure who is adding the /000000/.

But I can say for sure is that whatever the client software is doing, it works for all directories on the default disk.

It allows fully qualified path specification, e.g. CD DISKA:[DIR123.SUBDIROF123], as well as relative path specification, e.g.s CD [DIR123.SUBDIR123].

It handles both cases without any problems and I had no problem navigating all the directory structure on my default disk using the CD (CWD) command.

However, your question about SYS$LOGIN spec raises an interesting question, is it possible that for one user the spec on DISKA is to have 000000 as the root directory and on DISKB not to?

The only problem is observed when specifying a path on a different disk (DISKB instead of DISKA).

Whether the root cause is the fact that the directory is on another disk, or perhaps the SFTP server process may not have inherited all the user permissions so it cannot access this directory,  

This is what I need help with:  Diagnosing the reason why the SFTP server is responding with no such file to a directory path that is accessible to the user from the console.

 Many thanks for all your responses...

[Hoff]

Stop using the sftp client that you can't discuss (and for whatever reason), and lets work with and show the commands and sequences from PuTTY psftp or another a tool that you can discuss.  And turn on debugging within that tool.  That's usually -v or -vvv, but I don't have any Windows boxes to check that.

>How do you CD to a directory on a disk different than your default disk when using SFTP command line client to access an SFTP server on OpenVMS...... 

You cd to the directory.  Barring process-local logical name definition or login-level differences or something that's been site-specific configured to prevent this, there is no difference here. 

But what you get with ssh isn't necessarily the same environment you get with sftp, if your local login introduces a difference, or if the system manager (for instance) has enabled protections.  Or if there's a declaration error that's tripping up the sftp client.  This is site-specific, which is at the core of the "fun" here, but - unless this vendor has tested with the OpenVMS sftp tools - I still don't trust this unidentified sftp client, either.

To look for logical name declaration errors, on OpenVMS and from an ssh session, issue the commands:

SHOW LOGICAL/FULL DISKA

SHOW LOGICAL/FULL DISKB

Repeat each SHOW LOGICAL /FULL for the device portion of each of the translations, until you get to a physical device specification.  

Post the results.

You have concealed rooted logical names here, and potentially poorly-defined definitions.  (The 000000 is usually triggered from a concealed rooted logical name.)

Also see if DISKB is defined in your local login or in a particular sylogin context somewhere, and not (for instance) defined system-wide.  If there's a reason why you're not getting a translation.  To test this, use the physical translation and directory specifications from the SHOW LOGICAL/FULL DISKB sequence above to construct a physical directory path, and test with that.

The usual syntax for the sftp verb is sftp user@host

Given you're a Windows user, also look at Filezilla.  That's free, and GUI-based.