SCP and SFTP problems

[Hans Jivesten]

Hi,

I'm facing exactly the same problem. I've tried both SSH Communication's Tectia client and the PuTTY clients. I've tried both SCP and SFTP neither works for me.

I've tested with OpenVMS 7.3-2 and TCPIP v5.4 ECO 4 without success. I've also tried using Process' Multinet TCPIP software with the same bad result.

I can list files using "pcsp -ls" but I can't transfer them. I get "unknown error".

This is what pscp looks like:

C:\Program\PuTTY>pscp -v qrajive@192.168.65.90:test.bas test.bas
Server version: SSH-2.0-2.4.1 SSH Secure Shell OpenVMS V1.0
We claim version: SSH-2.0-PuTTY-Release-0.56
Using SSH protocol version 2
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-dss 1024 ac:62:02:21:60:6d:0b:24:6e:f5:f2:71:b7:f1:16:30
Initialised Blowfish client->server encryption
Initialised Blowfish server->client encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "qrajive".
qrajive@192.168.65.90's password:
Sent password
Access granted
Opened channel for session
Started a shell/command
Using SFTP
Connected to 192.168.65.90

pscp: unable to open test.bas: unknown error code
Sent EOF message

C:\Program\PuTTY>

SSH Comm's client gives me:
Error 8: open: test.bas;1 (src) invalid handle(?)

the file is there:
C:\Program\PuTTY>pscp -v -ls qrajive@192.168.65.90:
Server version: SSH-2.0-2.4.1 SSH Secure Shell OpenVMS V1.0
We claim version: SSH-2.0-PuTTY-Release-0.56
Using SSH protocol version 2
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-dss 1024 ac:62:02:21:60:6d:0b:24:6e:f5:f2:71:b7:f1:16:30
Initialised Blowfish client->server encryption
Initialised Blowfish server->client encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "qrajive".
qrajive@192.168.65.90's password:
Sent password
Access granted
Opened channel for session
Started a shell/command
Using SFTP
Connected to 192.168.65.90

Listing directory .
TEST.BAS;1
Sent EOF message

plink works fine, however:
C:\Program\PuTTY>plink -v qrajive@192.168.65.90 "tcpip show version"
Server version: SSH-2.0-2.4.1 SSH Secure Shell OpenVMS V1.0
We claim version: SSH-2.0-PuTTY-Release-0.56
Using SSH protocol version 2
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-dss 1024 ac:62:02:21:60:6d:0b:24:6e:f5:f2:71:b7:f1:16:30
Initialised Blowfish client->server encryption
Initialised Blowfish server->client encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "qrajive".
qrajive@192.168.65.90's password:
Sent password
Access granted
Opened channel for session
Started a shell/command


HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 4
on a DEC 3000 - M300X running OpenVMS V7.3-2

Server sent command exit status 0
All channels closed. Disconnecting

C:\Program\PuTTY>

puTTY as well as SSH Tectia SSH terminal clients works OK for interactive use.

I've tried specifying test.bas;1 etc. without success...

Any help welcome.

best regards,
Hans Jivesten

[Martin Vorlaender]

Hi Hans,

as I said in comp.os.vms, I don#t have problems with pscp+MultiNet. I do have the same problems you describe with HP TCP/IP Services, though. Testing SCP locally - trying to copy login.com - gives (with "-D" 1):

tcpip$ssh_scp2.exe: warning: login.com (source): Not supported record format.

(with "-D" 2 the SCP client crashes ;-( )

So it seems TCP/IP Services is quite restrictive WRT te supported file formats. I haven't seen such behaviour with MultiNet.

cu,
Martin

[Hans Jivesten]

Hi Martin,

With Multinet I couldn't even do pscp -ls, let alone copy any files. PuTTY it self worked fine though as do PLink, as you can see.

I haven't tried scp from another VMS machine since I don't have one. But I'll try to find one.

HP states that it has tested the PuTTY and SSH Comm clients OK with SSH and TCPIP v5.4.

Also there are people saying it works fine.

best regards,
Hans Jivesten

[Martin Vorlaender]

Hans,

my TCP/IP Services SCP client+server test was simply:

$ SET DEF SYS$SYSDEVICE:[TEMP]
$ SCP "-D" 1 "system@localhost:login.com" login.com

From the error message, it seems that SCP doesnt't like LOGIN.COM's record format (Variable length). I haven't yet tried to transfer a STREAM_LF file.

cu,
Martin

[Martin Vorlaender]

Okay, so I tested a STREAM_LF file (just took a copy of LOGIN.COM and $ SET FILE/ATTR=RFM:STMLF), and it now *worked*!

cu,
Martin

P.S.: I'd suggest to switch back to MultiNet, and we try to solve your problem there.

[Hans Jivesten]

Hi Martin,

Thanks for your tip on STREAM_LF. Not that I understand why that and nothing else should work.

Maybe I will do another try with Multinet, but I had so manyother problems with it. The installation didn't create any SMTP queues or logicals at all and once I thought I had it all figured out I couldn't send mail anyway.

As I said I got puTTY working without any problems but pscp and psftp worked just as bad with Multinet. Even "pscp -ls" would come back with no result.

I'm surprised HP doesn't answer any of these questions on SCP and SFTP. They clearly state it should work. I didn't even get SCP to work from/to the same machine unless it's a STREAM_LF file.

It can't be as bad as that can it?

best regards,
Hans Jivesten

[Feinberg Parker]

Greetings,

Does anyone know why SFTP does not support ASCII file transfer ? We are running SFTP on all our HPUX server and find that we cannot transfer ASCII files without first converting them first. Any ideas would be helpfull.

Thanks,

Al

[Willem Grooters]

In other words: USELESS SOFTWARE.

This is - once again - a proof of bad porting of open source (that is: U*x) code to VMS.
When will HP FINALLY do things right and have this software use files AS IS - in their NATIVE format?

Willem

[Ian Miller.]

the restriction to stream_lf (and fixed 512 byte ?) is documented - parhaps in the release notes. hp are aware how irritating it is but the more people complain then parhaps it helps to get it up the priority list.

[Martin Vorlaender]

>>>
hp are aware how irritating it is but the more people complain then parhaps it helps to get it up the priority list.
<<<

IMHO it should be rated higher for the fact that Process' SSH implementation does not have such limitations.

cu,
Martin

[Jan van den Ende]

Combine Ian:

hp are aware how irritating it is

and Willem
This is - once again - a proof of bad porting of open source (that is: U*x) code to VMS.

and you do not get an oversight, but deliberate contempt for VMS.
And I think that that is a shame!


the fact that it accepts ONLY the NIX type of file seems to suggest that it does its own filehandling, bypassing RMS.
--- should--- I be right in that, what then are the possible repercussions w.r.t. multiple file versions, and clusterwide concurrent access issues?


Proost.

Have one on me.

jpe

[Jeremy Stubbs]

The (Current) workaround for file formats other than Fixed 512 byte records and Stream_lf is of course to use FTP over a secure tunnel ;0)

Therein lies another story