cancel
Showing results for 
Search instead for 
Did you mean: 

scp problem

 
SOLVED
Go to solution
Mark Battle
Advisor

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

I am using OpenVMS V8.2

Any ideas?
5 REPLIES 5
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.
Hoff
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.

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

Re: scp problem

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'
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: scp problem

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

Re: scp problem

John,

Thanks. Defining sys$login solves the problem.