passwordless ssh for non-root user???

UNIX AIX
1

hi all

I have a problem to set up the password ssh login for a non-root user. what I want to do is that non-root user in host A logs into host B without password prompted.

what I did listed as the following steps.

  1. genarate a pair of keys from host A.
ssy-keygen -t rsa -N "" -f ~/.ssh/id_rsa

2.copy the public key to host B

scp -p ~/.ssh/id_rsa/pub hostb:~/.ssh/id_rsa.`hostname`.pub

3.create the authorized_key file from the public key

cat ~/.ssh/id_rsa.hostb.pub >> ~/.ssh/authorized_keys

after that, i have checked the permission both host A and host B. the .ssh has 700 in both hosts and the private key in host A has 600 and the authorized_keys in host B has 644.

when I tested the ssh connection, it still looks like this.

ontstcerwpar1racle.:/home/oracle/.ssh>ssh -v ontstcer2
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: init_func_ptrs success
debug1: Value of krb5 is 1
debug1: Value of gssapi is 1
debug1: Connecting to ontstcer2 [172.15.103.87] port 22.
debug1: Connection established.
debug1: identity file /home/oracle/.ssh/identity type -1
debug1: identity file /home/oracle/.ssh/id_rsa type 1
debug1: identity file /home/oracle/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.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: 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 'ontstcer2' is known and matches the RSA host key.
debug1: Found key in /home/oracle/.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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/oracle/.ssh/identity
debug1: Offering public key: /home/oracle/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/oracle/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
oracle@ontstcer2's password:

any idea why this happens?

thanks in advance,

Frank

2

It might be an older version of SSH demanding DSA keys instead of RSA ones.

1 Like
3

i tried them all. none of them worked.

4

I think what you need, is to run ssh-agent.

I have a user that logs in without supplying a passphrase or a password, but when I first log in I run ssh-agent to cache the passphrase in memory.

If in fact you are using AIX, you might try:

   
   HOME=/
   export HOME
   /usr/local/bin/keychain $HOME/.ssh/id_rsa $HOME/.ssh/id_dsa
   . $HOME/.ssh-agent-$(hostname)
5

this command /usr/local/bin/keychain does not exit in AIX.

but I did checked the HOME for oracle user. it shows correct.

6

Try 'find'ing keychain.

7

I did a gloable search for this file and found nothing.

8

Hi,

who owns the authorized_keys file (should be oracle) and ... try to copy it and name it authorized_keys2 - that sometimes helps for reasons I do not know ...

What kind of security environment do you have - in my company you would have to have an accessroute defined between these hosts and public key authentication permitted for the user.

Regards
zxmaus

9

Hey,

There could be two things:

1) check your sshd_config, maybe you are looking the file at the wrong place.

2) when you created your ssh key, did you put in a passphrase ? If so, you will need a ssh-agent to run with the ssh-key set into it.

10

I use a similar setup between two AIX boxes. Here is what I see in the debug log when I ssh into the remote host:

> ssh -v hostB
OpenSSH_3.8.1p1, OpenSSL 0.9.6m 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so):   0509-022 Cannot load module /usr/krb5/lib/libkrb5.a(libkrb5.a.so).
        0509-026 System error: A file or directory in the path name does not exist.

debug1: Error loading Kerberos, disabling Kerberos auth.
debug1: Connecting to hostB [10.3.9.33] port 22.
debug1: Connection established.
debug1: identity file /home/userX/.ssh/identity type -1
debug1: identity file /home/userX/.ssh/id_rsa type 1
debug1: identity file /home/userX/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
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 'hostB' is known and matches the RSA host key.
debug1: Found key in /home/userX/.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,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/userX/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

In my experience with setting up the SSH key-based authentication, I found that the whole system is very strict about file permissions. Make sure you have the following file permissions on hostB:

~/.ssh/authorized_keys  600
~/.ssh                  700
~                       755

Note that home directory permissions are very important as well... if your home directory is writable by other users, SSHD would not accept the key.

HTH!