scp problem

Go to solution
Mark Battle

scp problem

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 which would cause it to work.

I am using OpenVMS V8.2

Any ideas?
Richard Whalen
Honored Contributor

Re: scp problem

What kind of authentication is used interactively?

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

Re: scp problem

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.

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
Honored Contributor

Re: scp problem


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:


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:

$ syslogin=F$PARSE(self,,,"DEVICE")+F$PARSE(self,,,"DIRECTORY")
$ DEFINE SYS$LOGIN 'syslogin'
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: scp problem


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:


(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.
A crucible of informative mistakes
Mark Battle

Re: scp problem


Thanks. Defining sys$login solves the problem.