topic Re: incorrect sys$login value during sftp session in Operating System - OpenVMS

incorrect sys$login value during sftp session

Gilles Pion — Tue, 17 Jul 2007 07:13:40 GMT

Hello all,
I'm looking for help on a sftp problem found on our configuration.

Context:
* tcpip show version gives:
VMS/tcpip version:
HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a AlphaServer ES40 running OpenVMS V7.3-2
* sftp "-V" gives:
$1$dga600:[sys0.syscommon.][sysexe]tcpip$ssh_sftp2.exe: SSH Secure Shell OpenVMS
(V5.5) 3.2.0 on AlphaServer ES40 - VMS V7.3-2

Evidence:
inside sftp session, "cd sys$login" incorrectly set default directory to tcpip$ssh user home directory:
$ sftp
Connecting to ...
sftp> cd sys$login
sftp> pwd
Remote working directory: /SYS$SYSDEVICE/tcpip$ssh <- incorrect

Before logging a support call I would like to know if someone using a more recent tcp/ip version could check if this has been fixed or not.

--
Gilles

Re: incorrect sys$login value during sftp session

Wim Van den Wyngaert — Tue, 17 Jul 2007 08:21:13 GMT

This is expected behaviour I think.

The SFTP process is a detached process. It has not all logicals of an interactive process. So, sys$scratch, sys$login are missing.

Wim

Re: incorrect sys$login value during sftp session

Wim Van den Wyngaert — Tue, 17 Jul 2007 09:17:58 GMT

You can however define sys$login for "Other" processes in your login.com. I tried it on multinet and that works. But by default the location is in sys$login of the user (but without the logical sys$login) !

Wim

Re: incorrect sys$login value during sftp session

Richard Whalen — Tue, 17 Jul 2007 10:03:25 GMT

MultiNet's (and TCPware's) SFTP server runs as a subprocess of a logged process that uses a fta device for a terminal. The MultiNet/TCPware SFTP server has all of the user's normal logical names available and runs with the user's identity so all of the normal VMS security functions work.

Re: incorrect sys$login value during sftp session

Wim Van den Wyngaert — Tue, 17 Jul 2007 10:15:14 GMT

Richard is right. Multinet has sys$login and sys$scratch defined. And mode returned "OTHER" which I translated to detached. But I guess the HP version could be different.
Replace in the following xxx by the process id created for your sftp session.

$ ana/sys
set proc/id=xxx
$clue proc/logical

and check for yourself.

Wim

Re: incorrect sys$login value during sftp session

Gilles Pion — Tue, 17 Jul 2007 10:30:42 GMT

I had previously already defined sys$login and sys$scratch inside sylogin with the following commands:
$ if f$trnlnm("sys$login") .eqs. "" then -
define/job sys$login 'f$environment("default")
$ if f$trnlnm("sys$scratch") .eqs. "" then -
define/job sys$scratch 'f$environment("default")

So the problem is not sys$login undefined but having an invalid value.

But further investigations show that things are even more strange:
"cd sys$login" works fine if the sftp client is running on another vms host,
it doesn't work when coming from a solaris host using openssh or from Windows PC using putty's psftp command!

Weird...

Re: incorrect sys$login value during sftp session

Wim Van den Wyngaert — Tue, 17 Jul 2007 10:34:51 GMT

I checked it with 5.3 eco 2 with eak.

In multinet you get a process logical sys$scratch and sys$login.

In HP you get a job logical sys$login and sys$scratch. Both pointing to what you found. Thus you found an error.

Also the login.com is not executed. So, it doesn't know your environment.

Wim