- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: scp problem
-
- Forums
-
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Middle East
- HPE Blog, Russia
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
-
Blogs
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Blog, Latin America
- HPE Blog, Middle East
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
-
Information
- Community
- Welcome
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Tips and Tricks
- Resources
- Announcements
- Email us
- Feedback
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Aruba Airheads Community
- Enterprise.nxt
- HPE Dev Community
- Cloud28+ Community
- Marketplace
-
Forums
-
Blogs
-
Information
-
English
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-28-2011 06:37 AM
01-28-2011 06:37 AM
$ 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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-28-2011 08:30 AM
01-28-2011 08:30 AM
Re: scp problem
For it to work as a batch job it will need to use publickey or hostbased.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-28-2011 09:18 AM
01-28-2011 09:18 AM
Re: scp problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-30-2011 12:43 PM
01-30-2011 12:43 PM
SolutionKeys 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'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-30-2011 12:52 PM
01-30-2011 12:52 PM
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:
/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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-31-2011 06:08 AM
01-31-2011 06:08 AM
Re: scp problem
Thanks. Defining sys$login solves the problem.
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2021 Hewlett Packard Enterprise Development LP