scp problem

[Mark Battle]

I have a script which uses scp so send a file to a remote system. It works fine from a Decterm or if I submit it, but fails when spawned from a task which is stated by run/detach. i.e f$mode = 'OTHER'

$ scp "OBRQ_110125JSMP_16461648_2307.CR" cmpsops@cweb...:/home/cmpsops/clu_usr/Input_Area/OBRQ_110125JSMP_16461648_2307.CR

tcpip$ssh_scp2.exe: warning: ssh2 client failed to authenticate. (or you have too old ssh2 installed, check with ssh2 "-V")

tcpip$ssh_scp2.exe: warning: child process (/sys$system/tcpip$ssh_ssh2) exited with code 27.

%TCPIP-E-SSH_FC_ERROR, undetermined error within sshfilecopy



I don't see anything obvious in my login.com which would cause it to work.

I am using OpenVMS V8.2

Any ideas?

[Richard Whalen]

What kind of authentication is used interactively?

For it to work as a batch job it will need to use publickey or hostbased.

[Hoff]

Generic shotgun answer...

Definitely check the scheme used, as mentioned.

$ x=f$mess(27)
$ sho sym x
X = "%SYSTEM-I-EXQUOTA, process quota exceeded"
$ x=f$mess(%x27)
$ sho sym x
X = "%SYSTEM-?-NOPRIV, insufficient privilege or object protection violation"
$

The second translation is clearly bogus. The first looks questionable.

When you start detached processes, the whole list of quotas is usually obligatory.

$ sear sys$sysroot:[decc$lib...]errno.h 27
...
#define EFBIG 27 /* File too large */

And when debugging these cases, it can be useful to start start the detached process by running the LOGINOUT image, so you get access to a CLI.

And also re-try the sequence with the requested -vvv debugging switch (that's the scp "-V" stuff) to troubleshoot what may be happening with the authentication.

And definitely also have a look at the PRC$M_NOUAF bit or the /AUTHORIZE qualifier to the process creation to get the process logical names. Omitting that knob can mess up some of these cases; missing process logical names.

http://snow.hoffmanlabs.net/node/318

And make sure your detached processes can read your private key files; that you're running with the same user context.

Reposting this as ITRC is being even more like, well, ITRC again today. More ITRC than usual.

[John Gillings · Accepted solution]

Mark,

Keys are kept in the SSH2 sub directory of SYS$LOGIN. Depending on how you start your process, you may be missing some logical names (SYS$LOGIN, SYS$SCRATCH etc...). Without them, SSH can't locate the keys, and therefore can't authenticate.

Replace your scp procedure with some diagnostics. Simple start:

$ SHOW LOGICAL/PROC
$ SHOW LOGICAL/JOB

Catch the output and compare with the output when run from a working environment.

See what's defined or not. If anything is missing, run something to define them.

Simplest way to locate yourself is to store the procedure in SYS$LOGIN and use F$ENVIRONMENT

For example:

$ self=F$ENVIRONMENT("PROCEDURE")
$ syslogin=F$PARSE(self,,,"DEVICE")+F$PARSE(self,,,"DIRECTORY")
$ DEFINE SYS$LOGIN 'syslogin'
$ DEFINE SYS$SCRATCH 'syslogin'

[John Gillings]

Mark,

As Hoff has noted, you may also have a quota issue. Search for RUN/DETACH commands in SYS$STARTUP:*.COM. Somewhere you'll find a fully populated set of quotas. Copy and paste into your RUN command and maybe copy values from the current process, for example:

/AST_LIMIT='F$GETJPI("","ASTLM") -
/BUFFER_LIMIT='F$GETJPI("","BYTLM") -
/ENQUEUE_LIMIT='F$GETJPI("","ENQLM") -
/QUEUE_LIMIT='F$GETJPI("","TQELM")

(wouldn't it have been nice if the RUN command, AUTHORIZE and $GETJPI were consistent with quota names?)

Unfortunately, the way $CREPRC works (and thus RUN/DETACHED), a naked RUN command without an explicitly populated set of quotas is almost certainly not what you want.

[Mark Battle]

John,

Thanks. Defining sys$login solves the problem.