Operating System - Tru64 Unix
1753617 Members
5915 Online
108797 Solutions
New Discussion юеВ

Re: Problem with scp from Solaris ssh to tru64 ssh2

 
JESUS HIGUERAS
Advisor

Problem with scp from Solaris ssh to tru64 ssh2

Hi,

I try to do scp from solaris 9 with ssh to tru64 5.1B with ssh2.
I have put de public key in the .ssh and .ssh2 directory in tru64 system but it doesn't work ok.

I get the following message and i don't know how to configure it.

I need help,
Thank you.
Jes├║s.

$ ssh -v hp1
SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: getuid 100 geteuid 100 anon 1
debug1: Connecting to hp1 [10.75.16.135] port 22.
debug1: Connection established.
debug1: identity file /export/home/[user]/.ssh/identity type 3
debug1: identity file /export/home/[user]/.ssh/id_rsa type 3
debug1: Bad RSA1 key file /export/home/[user]/.ssh/id_dsa.
debug1: identity file /export/home/[user]/.ssh/id_dsa type 3
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
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.0.1
debug1: sent kexinit: diffie-hellman-group1-sha1
debug1: sent kexinit: ssh-rsa,ssh-dss
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: aes128-cbc,blowfish-cbc,3des-cbc,rijndael128-cbc
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: hmac-sha1,hmac-md5
debug1: sent kexinit: none
debug1: sent kexinit: none
debug1: sent kexinit:
debug1: sent kexinit:
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit: diffie-hellman-group1-sha1
debug1: got kexinit: ssh-dss
debug1: got kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour,des-cbc@ssh.com,rc2-cbc@ssh.com
debug1: got kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour,des-cbc@ssh.com,rc2-cbc@ssh.com
debug1: got kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ssh.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger192-96@ssh.com
debug1: got kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ssh.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger192-96@ssh.com
debug1: got kexinit: none,zlib
debug1: got kexinit: none,zlib
debug1: got kexinit:
debug1: got kexinit:
debug1: first kex follow: 0
debug1: reserved: 0
debug1: done
debug1: kex: server->client unable to decide common locale
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: kex: client->server unable to decide common locale
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug1: Sending SSH2_MSG_KEXDH_INIT.
debug1: bits set: 501/1024
debug1: Wait SSH2_MSG_KEXDH_REPLY.
debug1: Got SSH2_MSG_KEXDH_REPLY.
debug1: Host 'hp1' is known and matches the DSA host key.
debug1: Found key in /export/home/[user]/.ssh/known_hosts:16
debug1: bits set: 522/1024
debug1: len 55 datafellows 0
debug1: ssh_dss_verify: signature correct
debug1: Wait SSH2_MSG_NEWKEYS.
debug1: GOT SSH2_MSG_NEWKEYS.
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: done: KEX2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: hostbased,publickey,password
debug1: next auth method to try is publickey
debug1: key does not exist: /export/home/[user]/.ssh/identity
debug1: key does not exist: /export/home/[user]/.ssh/id_rsa
debug1: try pubkey: /export/home/[user]/.ssh/id_dsa
debug1: read SSH2 private key done: name dsa w/o comment success 1
debug1: sig size 20 20
debug1: authentications that can continue: hostbased,publickey,password
debug1: next auth method to try is publickey
debug1: next auth method to try is password
[user]@hp1's password:
3 REPLIES 3
Steven Schweda
Honored Contributor

Re: Problem with scp from Solaris ssh to tru64 ssh2

Tru64 uses SSH2, while Solaris uses OpenSSH,
so the key file formats are different. Where
did you make your keys? On Solaris,
ssh-keygen has a "-X" or "-i" option
(depending on the version) which lets you
convert an SSH2 key file to OpenSSH format
("man ssh-keygen" on Solaris).

Also, If my memory is working, on the Tru64
side, you need "~/.ssh2/authorization", which
contains the names of the the valid public
key files (the file _names_, _not_ the key
data themselves).

I don't remember if there's a simple way to
convert all OpenSSH key files to SSH2, but
the public keys can done using a text editor.
If you use ssh-keygen to make a set of keys
on the Tru64 system, you can see the required
format. After that, you just need to edit an
OpenSSH key file until it looks like that.

If you still have trouble, it might help to
know what's in your ".ssh[2]" directories on
both ends.
Brendan Murphy_5
Frequent Advisor

Re: Problem with scp from Solaris ssh to tru64 ssh2

Aside from the issue of different layout for the RSA/DSA public keyfiles, there is a problem with scp compatability between the Tru64 BSD based version of SSH kit & the Solaris OpenSSH based verion kit. The only workaround for this that I have been able to come up with is to compile OpenSSH on a Tru64 system, & copy the scp binary into /usr/bin as scp1. I think the installed Tru64 version of scp falls back to scp1 so when running scp requests from Solaris to tru64, it should work OK.

Brendan
Kasper Hedensted
Trusted Contributor

Re: Problem with scp from Solaris ssh to tru64 ssh2

Hi,

I found out that I could convert these files myself:

In the .ssh2 directory create a file called "authorization".

In the file you put the name of a key-file for example:

server_a> cat authorization
Key server_b.pub

In the key-file you need to put the public-key (the user from the connecting server) and a add a top- and bottom-line like this:

server_a> cat Key server_b.pub
---- BEGIN SSH2 PUBLIC KEY ----
LSy7gkR9_ENTIRE_SSH_KEY_kskdssjfshfejw
---- END SSH2 PUBLIC KEY ----

As for the scp issue, I also use the workaround by compiling OpenSSH and the copy the scp binary to /usr/bin/scp1.


Regards,
Kasper