Security
cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with using scp between Linux and Tru64

Andy_K
Occasional Visitor

Problems with using scp between Linux and Tru64

Hi,

I am trying to use scp between a Linux box (Slackware) and Tru64. Linux box is Slackware 9.1 with Openssh 3.8p1, but I can't get it to work. Below is the output I get on the screen.

scp -v syscheck.tar.gz user@system:/usr/users/user
Executing: program /usr/bin/ssh host , user user, command scp -v -t /usr/users/user
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to system port 22.
debug1: Connection established.
debug1: identity file /home/kannberg/.ssh/identity type -1
debug1: identity file /home/kannberg/.ssh/id_rsa type -1
debug1: identity file /home/kannberg/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure Shell Tru64 UNIX
debug1: no match: 3.2.0 SSH Secure Shell Tru64 UNIX
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 aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'xxxxxx' is known and matches the DSA host key.
debug1: Found key in /home/kannberg/.ssh/known_hosts:5
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/kannberg/.ssh/identity
debug1: Trying private key: /home/kannberg/.ssh/id_rsa
debug1: Trying private key: /home/kannberg/.ssh/id_dsa
debug1: Next authentication method: password
toor@itiu33's password:
Connection closed by 10.0.0.0
debug1: Calling cleanup 0x8063320(0x0)
lost connection

Here is another try with the -v option

kannberg@xxxxxx:~$ scp -v syscheck.tar.gz kannberg@xxxxxx:/home/kannberg
Executing: program /usr/bin/ssh host xxxxx, user kannberg, command scp -v -t /home/kannberg
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xxxxxx port 22.
debug1: Connection established.
debug1: identity file /home/kannberg/.ssh/identity type -1
debug1: identity file /home/kannberg/.ssh/id_rsa type -1
debug1: identity file /home/kannberg/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure Shell Tru64 UNIX
debug1: no match: 3.2.0 SSH Secure Shell Tru64 UNIX
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 aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'itiu33' is known and matches the DSA host key.
debug1: Found key in /home/kannberg/.ssh/known_hosts:5
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/kannberg/.ssh/identity
debug1: Trying private key: /home/kannberg/.ssh/id_rsa
debug1: Trying private key: /home/kannberg/.ssh/id_dsa
debug1: Next authentication method: password
kannberg@itiu33's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /home/kannberg
scp: warning: Executing scp1.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH).
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 255
lost connection

I've already generated a new keypair and converted them to the ssh.com format, I also created an authorities file in the .ssh2 dir, but this also didn't work. Is there a way to get this working, or should I simply install openssh on the tru64 box ?

best regards,
Andy Kannberg
The Netherlands
6 REPLIES
Ivan Ferreira
Honored Contributor

Re: Problems with using scp between Linux and Tru64

Hi, see this thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=604250
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Archunan Muthiah
Honored Contributor

Re: Problems with using scp between Linux and Tru64

Andy,

I hope you might have to convert the public key on the Linux bosx to SSH format using this cmd...

ssh-keygen -e

cut,paste this command output on the key file "authorization file" in TU64's .SSH dir.


Archunan
God is Artist, we are all just brushes
Andy_K
Occasional Visitor

Re: Problems with using scp between Linux and Tru64

Archunan,

Thanks for your reply. I already have created a new key pair and converted them to ssh-format. But it still doesn't work.
Andy_K
Occasional Visitor

Re: Problems with using scp between Linux and Tru64

Ivan,

I checked the thread, but it doesn't add anything new I haven't already tried. Only thing I could filter out is that one should install Openssh in favour of the ssh.com package of Tru64.
Matt Palmer_2
Respected Contributor

Re: Problems with using scp between Linux and Tru64

Hi,

I had this problem, and it was because the Tru64 version doesnt scale backwards very well to SSH1 protocol.

what is documented to be done to get around this issue is:

edit this file:
/etc/ssh2/ssh_config

this section needs changing, in the docs there are 3 different modes(none,ssh2 or traditional) - I think I tried traditional for compatibility with ssh1. I had little joy with any of them.

## SSH1 Compatibility

Ssh1Compatibility yes
Ssh1AgentCompatibility none
# Ssh1AgentCompatibility traditional
# Ssh1AgentCompatibility ssh2
# Ssh1Path /usr/local/bin/ssh1


Finally, it may be easier to just install ssh1 on tru64 if the security isnt a large concern for you.

HTH

Regards

Matt Palmer
Steven Schweda
Honored Contributor

Re: Problems with using scp between Linux and Tru64

You might wish to skip to the end of this
mess, but having copied all this stuff into
this annoyng little text box, I'm not
deleting any of it.

I don't have a Linux system here, but
Solaris 10 seems to look similar, and I have
that working.

sol> uname -a
SunOS sol 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-60

sol> ssh -V
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

sol> ssh -v urtx
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to urtx [10.0.0.8] port 22.
debug1: Connection established.
debug1: identity file /usr/users/sms/.ssh/identity type -1
debug1: identity file /usr/users/sms/.ssh/id_rsa type -1
debug1: identity file /usr/users/sms/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure Shell Tru64 UNIX
debug1: no match: 3.2.0 SSH Secure Shell Tru64 UNIX
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: dh_gen_key: priv key bits set: 129/256
debug1: bits set: 481/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'urtx' is known and matches the DSA host key.
debug1: Found key in /usr/users/sms/.ssh/known_hosts:3
debug1: bits set: 536/1024
debug1: ssh_dss_verify: signature correct
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/users/sms/.ssh/identity
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey)
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 100000 rmax 16384
Last successful login for sms: Wed Mar 22 05:19:58 CST 2006 from sol.antinode.
org
Last unsuccessful login for sms: Wed Feb 1 18:47:21 CST 2006 on pts/2

Compaq Tru64 UNIX V5.1B (Rev. 2650); Sat Jan 28 11:47:04 CST 2006
No mail.
urtx>

urtx> ssh -V
ssh: SSH Secure Shell Tru64 UNIX 3.2.0

urtx> sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Sat Jan 28 11:47:04 CST 2006


Note that where you see:

debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kannberg/.ssh/identity
debug1: Trying private key: /home/kannberg/.ssh/id_rsa
debug1: Trying private key: /home/kannberg/.ssh/id_dsa
debug1: Next authentication method: password

I see:

debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/users/sms/.ssh/identity
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey)

I interpret this as someone not liking your
key data. I created my keys on a VMS system
("SSH Secure Shell OpenVMS (V5.5) 3.2.0 on
COMPAQ Professional Workstation - VMS
V7.3-2"), but the key file format there seems
to agree with Tru64 (to which I copied them).
These key data files look like this:

urtx> cat /usr/users/sms/.ssh2/sms_npp_id_dsa_1024_a.pub
---- BEGIN SSH2 PUBLIC KEY ----
Subject: sms
Comment: "1024-bit dsa, sms@alp.antinode.org, Thu Jul 24 2003 03:43:07"
AAAAB3N[...]
[...]K9uu8WQ==
---- END SSH2 PUBLIC KEY ----

On the Solaris system, my
"$HOME/.ssh/identity" is a link to
"sms_npp_id_dsa_1024_a_sol" which leads to
files which looks different:

sol> cat $HOME/.ssh/sms_npp_id_dsa_1024_a_sol
-----BEGIN DSA PRIVATE KEY-----
MIIBugIB[...]
[...]j6gZnTs=
-----END DSA PRIVATE KEY-----

sol> cat $HOME/.ssh/sms_npp_id_dsa_1024_a_sol.pub
ssh-dss AAAAB3N[...]K9uu8WQ==

(That's one long record with the same data
as the original key file's multiple records.)

I created "sms_npp_id_dsa_1024_a_sol" from
the original "sms_npp_id_dsa_1024_a" so:

ssh-keygen -X -f sms_npp_id_dsa_1024_a >
sms_npp_id_dsa_1024_a_sol

and, similarly:

ssh-keygen -X -f sms_npp_id_dsa_1024_a.pub >
sms_npp_id_dsa_1024_a_sol.pub

I did that back on Solaris 9. The new "man
ssh-keygen" says to use "-i" instead of "-X",
but the result is the same.


I can get a failure like yours by removing
the "$HOME/.ssh/identity" link.

debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/users/sms/.ssh/identity
debug1: Trying private key: /usr/users/sms/.ssh/id_rsa
debug1: Trying private key: /usr/users/sms/.ssh/id_dsa
debug1: Next authentication method: password

Do you have a "$HOME/.ssh/identity"? If I
point mine to a corrupt key file, it still
fails, but differently:

debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/users/sms/.ssh/identity
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: hostbased,publickey,password
debug1: Trying private key: /usr/users/sms/.ssh/id_rsa
debug1: Trying private key: /usr/users/sms/.ssh/id_dsa
debug1: Next authentication method: password

And, if I use the wrong-format key file, I
get:

debug1: Authentications that can continue: hostbased,publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /usr/users/sms/.ssh/identity
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key '/usr/users/sms/.ssh/identity':


It begins to look (to me) as if the "Trying
private key: xxx" complaints (with nothing
else after them) are saying that it's not
finding any of the "xxx" key files.

If you don't have a "$HOME/.ssh/identity" (or
one of those other key files it's expecting
to find), then you need to use the "-i
identity_file" option on the "ssh" or "scp"
command.

Note that on Solaris, the stuff is in
"$HOME/.ssh", while on Tru64, it's in
"$HOME/.ssh2"

Or so it appears to me.