RSA between linux and hp-ux

[Richard Price_1]

I've successfully set-up ssh to work without a password between hp-ux 11.23 and linux 2.6.18 (redhat 5) using an rsa key.
But I can't get it to work between hp-ux 11.23 and linux 2.4.21 (redhat 3) using exactly the same config at user level.

I'm not in a position to be able to upgrade the redhat 3 server.

Any ideas ?

Best regards,

Richard.

[Steven Schweda]

> Any ideas ?

Any explanation of what "can't get it to
work" really means? The usual SSH diagnostic
involves adding "-v" to an "ssh" command, and
looking at the output. And then looking at
the system log file(s) on the server.

> [...] exactly the same config at user level.

Not really a complete description of
anything, is it?

A Forum search will find many old SSH
threads, showing this stuff in action.

[Steven E. Protter]

Shalom,

Well it would be helpful to see the error code you are getting in the redhat three server.

On the red hat system.

ssh-keygen -t rsa



Take an authorized_keys file from an HP-UX system and put it in the .ssh directory.

Make sure all the file ownership and permissions in .ssh, the home directory are owned by the right users and match an working systems.

Here is a document.
http://www.hpux.ws/?p=10

That document works very well on HP-UX or Linux.

SEP

[Richard Price_1]

Yes. I've got it working very well between hp-ux 11.23 and linux 2.6.18 , but using the same methods, it's not working between hp-ux 11.23 and linux 2.4.21 .

I've checked all the usual file protection issues for the .ssh directory and the authorized_keys file. I've also tried calling it authorized_keys2 . I've cksummed authorized_keys and id_rsa.pub and they are identical.

[Steven Schweda]

> [...] it's not working [...]
>
> I've checked all the usual [...]
> I've also tried [...]
> I've cksummed [...]

About the only things you haven't done are:

1. Describe the problem.

2. Show the "ssh -v [...]" results.

3. Show the stuff from the server log file(s).

As usual, showing actual commands with their
actual output can be more helpful than vague
descriptions and interpretations.

As a minor example, saying something like,
"I've checked all the usual file protection
issues [...]" is not the same as showing
actual "ls -l" output. Perhaps you really do
know whereof you speak, but you are asking
about this stuff here, so, with no evidence,
your opinion might reasonably be suspect.

[Richard Price_1]

The -v is very useful ! thanks. Output below.

Unfortunately the remote system is a customer system and I can't easily have a look at the syslog on there. May be possible over the next few days.

Anyway here are the 2 ssh -v outputs...

Working...

OpenSSH_4.1, OpenSSL 0.9.7e 25 Oct 2004
HP-UX Secure Shell-A.04.00.001, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to xxxxxx [xxxxxx] port 22.
debug1: Connection established.
debug1: identity file /home/users/xxxxxx/.ssh/id_rsa type 1
debug1: identity file /home/users/xxxxxx/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxxxxx' is known and matches the RSA host key.
debug1: Found key in /home/users/xxxxxx/.ssh/known_hosts:3
debug1: ssh_rsa_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: publickey,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/users/xxxxxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Oct 8 15:38:27 2009 from xxxxxx


Not Working...

OpenSSH_4.1, OpenSSL 0.9.7e 25 Oct 2004
HP-UX Secure Shell-A.04.00.001, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to 172.1xxxxxxx [172.1xxxxxxx] port 22.
debug1: Connection established.
debug1: identity file /home/users/xxxxxx/.ssh/id_rsa type 1
debug1: identity file /home/users/xxxxxx/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxxxxxx' is known and matches the RSA host key.
debug1: Found key in /home/users/xxxxxx/.ssh/known_hosts:1
debug1: ssh_rsa_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: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/users/xxxxxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/users/xxxxxx/.ssh/id_dsa
debug1: Next authentication method: password

At this point the system prompts for a password.

[rick jones · Accepted solution]

RHEL3 is *very* old - wasn't there some sort of ssh version roll to address a vulnerability at some point? Perhaps the UX ssh is unwilling to speak to the older version from the RHEL3 system?

[Steven Schweda]

> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/users/xxxxxx/.ssh/id_rsa
> debug1: Server accepts key: pkalg ssh-rsa blen 149
> debug1: read PEM private key done: type RSA
> debug1: Authentication succeeded (publickey).

Yup, that's a happy server.

> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/users/xxxxxx/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/users/xxxxxx/.ssh/id_dsa
> debug1: Next authentication method: password

Your SSH client sent both keys ("id_rsa" and
"id_dsa", assuming that those files exist) to
the server, and the server didn't like either
of them. At this point, I'd try to see
what's in the server's log file(s), because
only the server knows why it didn't like
them.

[dirk dierickx]

i'm guessing something is probably wrong with your public keys. it should not be a problem.

compare the versions of SSH/SSL on all involved servers. check your syslog, it might contain more information on why the keys were not accepted.

[Richard Price_1]

Thanks for your help everyone.

It's working now.

It was the permissions on the home directory of the remote system ( not the .ssh directory).

/home/ was 770

I set it to 750 and it all works now.

[Steven Schweda]

> It was the permissions on the home
> directory of the remote system ( not the
> .ssh directory).

If one's bad, then a villain can change the
other.

Curiosity: How did you find the problem?
Log files? Guesswork? ???

[Richard Price_1]

In this case a villian in the group.

As for how fixed...

Trial and error I suppose. Some might say guesswork :-)

We tested from a system at the same rev level as the target system and that didn't work either so I revisited all the permission issues again. I was too fixed on .ssh and authorized_keys. In mitigation , this is what the help pages keep banging on about.

Thanks again.