SSH trusting misbehaving!

[Matt Hearn]

Hi all! We're having a funny situation here. We have a couple accounts on a server that a customer needs to be able to access without using a PW. So he created a public RSA key and added it to the authorized_keys on both accounts. Unfortunately, one of them works, and one of them does not. Here's a truncated ssh -vvv on the one that works:

debug1: authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/jlebaron/.ssh/identity
debug3: no such identity: /home/jlebaron/.ssh/identity
debug1: try pubkey: /home/jlebaron/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 4002bb98 hint 1
debug2: input_userauth_pk_ok: fp 87:c8:d6:e2:58:c2:49:02:27:90:64:9c:6a:f6:f9:8c
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.

Et cetera. Here's the one that DOESN'T work:

debug1: authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/jlebaron/.ssh/identity
debug3: no such identity: /home/jlebaron/.ssh/identity
debug1: try pubkey: /home/jlebaron/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password
debug1: try pubkey: /home/jlebaron/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
aissup@localhost's password:

Looks like it sends both the RSA and DSA keys and gets no response from the account! Any ideas? Do I need to generate fresh public/private keys for the aissup account (the one that's broken)? I'm afraid that might screw up trusting somewhere else (the aissup account is trusted by other things, I believe).

Thanks!

[Tim Nelson]

Check permissions on the .ssh and authorize_key files for the account that does not work.

If ssh finds the directory or file readable by anyone other than the user then it forces the challenge for manual password.

[Matt Hearn]

That's not strictly true; my root trusting works, and authorized_keys is 644. To be on the safe side, I chmoded the authorized_keys for the aissup user to 600 and get the same response. The .ssh directory for all the users seems to be 700.

We did try regenerating the RSA host keys for the aissup user, because we discovered that they had originally been generated on another server and copied over during a migration. That didn't help either.

[Haralambos]

Are the ssh connections in both istances initiated from the same user account and same ssh client?

If not try comparing the ssh_config or the user local config files under the .ssh directory.

On the server sire ensure that:
1. The $HOME/.ssh/authorized_keys files has te correct public key.
2. The public key in the file above is in one line.
3. Does the authorized_keys file use the "from=..." option? If yes ensure that the IP adrress and host name of the client are included in this key entry.
4. Ensure that the target account on the server site is NOT locked. check by doing `logins -xl `. If LK shows up instead of PS then the account is locked and ssh will not let you in, even when password authentication is used.

Haralambos