topic SCP Fails in Operating System - OpenVMS

SCP Fails

Winfried Wetzel — Tue, 27 Jul 2004 01:52:14 GMT

I try t copy a file via scp from a Unix Box to a OpenVMS WorkStation.
SCP fails without an errormessage.
There is no opcom message and there is no message in a Logfile.
For each try i got a process with the following name: TCPIP$SS_BGxxxx
I use public key authentication and if i try to connect the Alpha Workstation using "ssh username@hostname" it works.

TCPIP Version 5.4 ECO 2
OPENVMS 7.3-2

Has anyone an idea to solve the problem?

Thanks
Winfried

Re: SCP Fails

Kris Clippeleyr — Tue, 27 Jul 2004 05:40:44 GMT

Winfried,

I'm not that familiar with SSH, SCP & SFTP, but since you're able to connect to the VMS box using "ssh user@host" I assume the configuration is set up correctly.

Can you tell me if "scp -v" shows anything more on your Unix box?

Greetz,

Kris

Re: SCP Fails

Winfried Wetzel — Tue, 27 Jul 2004 06:13:25 GMT

Kris,

the debugmessages from scp -v seems to be normal as you can see:

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to leo [172.30.151.173] port 22.
debug1: Connection established.
debug1: identity file /home/stest/.ssh/id_rsa type -1
debug1: identity file /home/stest/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version 2.4.1 SSH Secure Sh
ell OpenVMS V1.0
debug1: match: 2.4.1 SSH Secure Shell OpenVMS V1.0 pat 2.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'leo' is known and matches the DSA host key.
debug1: Found key in /home/stest/.ssh/known_hosts:2
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/stest/.ssh/id_rsa
debug1: Offering public key: /home/stest/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t x.tmp

Re: SCP Fails

Kris Clippeleyr — Tue, 27 Jul 2004 06:45:39 GMT

Winfried,

According to the documentation I have, "If authentication succeeds and the user's identity has been accepted by the server, the server executes the command."

Since you do not specify a destination where to copy the file to, I expect the server tries to copy the file in the SYS$LOGIN of the user.
Is this directory writable by the server?

Could you enable auditing, like this
$ SET AUDIT/ALARM/ENABLE=ACCESS=FAIL
Then from an interactive session on the Alpha, do a
$ REPLY/ENABLE
And then re-execute the "scp" command from the Unix machine.
If any write access restrictions apply, you will see an alarm on the interactive session on the Alpha.

Greetz,

Kris

Re: SCP Fails

Winfried Wetzel — Tue, 27 Jul 2004 07:05:10 GMT

Kris,

what you see are the debugmessages from scp -v. The last line is a debug message and not the command.
The command was: scp -v x.tmp stest@leo:

I have tried this command between two openvms boxes and it works. But if i try this with a LinuxPC or a SUN Solaris Workstation, it doesn't work.

Winfried

Re: SCP Fails

Martin P.J. Zinser — Wed, 28 Jul 2004 21:17:04 GMT

Hi Winfried,

well ssh/scp is not yet a very mature part of TCP/IP :-( Prompted by your post I did install ECO2. SCP/SFTP got better, while it just crashed right away with 5.4 plain, I did get a partial success. It does work for me against a Linux system with
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f

although it still spews around plenty of messages a la

tcpip$ssh_scp2.exe: warning: packet length mismatch: expected 23, got 8; connec
tion to non-standard server?

(you could use -q to suppress these).

OTOH even a plain SSH fails completely versus another Linux box with
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004

Obviously the two Linux systems just talk fine to each other.

So maybe it is worth to check the SSH version on your Unix systems.

Greetings, Martin

Re: SCP Fails

Bart Buitenhuis_1 — Mon, 22 Aug 2005 09:36:16 GMT

Winfried,
have you tried to use full pathnames?

$ scp username@hostname.xxx.xxx.sss:/home/user/y.y user$disk:[xxx.xxx]t.t

works for me

Re: SCP Fails

Richard Whalen — Mon, 03 Oct 2005 08:48:47 GMT

If the Unix box is using OpenSSH (and odds are that it is), then SCP is actually RCP over SSH, which the SSH service in TCP/IP services does NOT provide a server for. Try using SFTP, which TCP/IP services does provide a server for.