TurboFTP and Multinet SFTP

[Tom Wade]

Greetings,

Multinet 4.4 with SSH patches on OpenVMS 7.3-1.

I'm trying to get the latest version of TurboFTP (V5.00) working with
Multinet (www.turboftp.com) and am not having much success. I'd be very
grateful to hear if anyone else has had more success.

Despite its claiming to be able to autodetect VMS systems the following
happens:

- with standard FTP it logs in but doesn't display the directory
contents correctly.

- with SFTP it logs in then says "Resolving path '.'" then hangs.

I can get the Standard FTP working by putting the following into the
user's LOGIN.COM file

$ Define MULTINET_FTP_UNIX_STYLE_BY_DEFAULT YES

But this has no effect on the SFTP session. Is the above logical
supposed to work for SFTP too ? Is there an equivalent of the
FTP_SERVER.LOG file for SFTP sessions that I can at least see what
command it is trying to send ?

Thanks for any help.

---------------------------------------------------------
Tom Wade | EMail: tee dot wade at eurokom dot ie
EuroKom | Tel: [phone]
A2, Nutgrove Office Park | Fax: [phone]
Rathfarnham | Disclaimer: This is not a disclaimer
Dublin 14 | Tip: "Friends don't let friends do Unix !"
Ireland

[Ken Connelly]

Tom -

Check out:

$ help multinet logical_names

Under MultiNet 5.1, there are several *sftp* logicals, including
MULTINET_SSH_SFTP_SERVER_DEBUG

Don't know what your mileage might be under 4.4...

-ken

Post by Tom Wade
Greetings,
Multinet 4.4 with SSH patches on OpenVMS 7.3-1.
I'm trying to get the latest version of TurboFTP (V5.00) working with
Multinet (www.turboftp.com) and am not having much success. I'd be
very grateful to hear if anyone else has had more success.
Despite its claiming to be able to autodetect VMS systems the
- with standard FTP it logs in but doesn't display the directory
contents correctly.
- with SFTP it logs in then says "Resolving path '.'" then hangs.
I can get the Standard FTP working by putting the following into the
user's LOGIN.COM file
$ Define MULTINET_FTP_UNIX_STYLE_BY_DEFAULT YES
But this has no effect on the SFTP session. Is the above logical
supposed to work for SFTP too ? Is there an equivalent of the
FTP_SERVER.LOG file for SFTP sessions that I can at least see what
command it is trying to send ?
Thanks for any help.
---------------------------------------------------------
Tom Wade | EMail: tee dot wade at eurokom dot ie
EuroKom | Tel: [phone]
A2, Nutgrove Office Park | Fax: [phone]
Rathfarnham | Disclaimer: This is not a disclaimer
Dublin 14 | Tip: "Friends don't let friends do Unix !"
Ireland

[Richard Whalen]

When I set out to do SFTP for MultiNet I decided that it would not support
all the logicals that MultiNet FTP supports. Despite my best efforts, I
have had to add quite a few logicals to control the behavior so that it can
work with the variety of implementations that there are to the protocol.

The SFTP server will create a log file telling you what it is doing by
defining the logical MULTINET_SSH_SFTP_SERVER_DEBUG. The simplest thing to
define it to is a an integer between 2 and 6, which is equivalent to the
DEBUG command to the SFTP client. When you know the various module names,
you can specify different debug levels for the various module names that are
of interest by putting "ModuleName=number" and separating each one with a
comma. Since case matters the whole thing needs to be in quotes.

SYS$LOGIN:SFTP-SERVER.LOG will contain detail about the various SFTP
protocol operations processed.

The first step recommended when there are startup issues with a client is to
restrict the protocol version that the SFTP server will operate at to 3
$ define MULTINET_SFTP_MAXIMUM_PROTOCOL_VERSION 3

I haven't tried TurboFTP at al, so I don't know what version of the SFTP
protocol they implement. Version 3 is pretty much universal and you get
good interoperability. Version 4 (the highest we support) offers true text
transfers, but isn't widely implemented and may have interoperability
problems.

[Richard Whalen]

I decided to take advantage of TurboFTP's trial period and install it and
test it against one of our systems with a significant amount of debugging
enabled.

Based upon what I see, it looks like it is NOT sending the SFTP
initialization command. (The first one that is supposed to be sent after
establishing the connection.) It's possible that it is sending the
initialization command and the SSH server didn't recognize it and send it
through, but this would be the first instance of that in a long time.