4

I have a new RHEL4 Linux box that I am using to copy data to old Solaris 2.6 and RHEL3 Linux boxes with scp. I have found that with the same setup, it works for some users but not for others. For user jane, this works fine:

jane@host1$ ssh -v remhost

debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/osborjo/.ssh/identity
debug1: Offering public key: /mnt/home/osborjo/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

for user jack it does not:

jack@host1 ssh -v remhost

debug1: Next authentication method: publickey
debug1: Trying private key: /mnt/home/oper1/.ssh/identity
debug1: Offering public key: /mnt/home/oper1/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive

I have looked at the permissions for all the keys and files, they look the same. Since I am using home directories mounted by NFS, the keys for both the remote host and the local host are in the same directory. This is how things look for jane:

jane@host1$ ls -l $HOME/.ssh

-rw-rw-r--   1 jane    operator     394 Jan 27 16:28 authorized_keys
-rw-------   1 jane    operator    1675 Jan 27 16:27 id_rsa
-rw-r--r--   1 jane    operator     394 Jan 27 16:27 id_rsa.pub
-rw-rw-r--   1 jane    operator    1205 Jan 27 16:46 known_hosts

For user jack:

jack@host1$ ls -l $HOME/.ssh

-rw-rw-r--   1 jack    engineer    394  Jan 27 16:28 authorized_keys
-rw-------   1 jack    engineer    1675 Jan 27 16:27 id_rsa
-rw-r--r--   1 jack    engineer    394  Jan 27 16:27 id_rsa.pub
-rw-rw-r--   1 jack    engineer    1205 Jan 27 16:46 known_hosts

As a last ditch effort, I copied the authorized_keys, id_rsa, and id_rsa.pub from jill to jack, and changed the username in authorized_keys and id_rsa.pub with vi. It still did not work. It seems there is something different between the two users but I cannot figure out what it is.

joshxdr
  • 257
  • 3
  • 15
  • This problem for user jack occurs when the client is RHEL4, the server is Solaris 2.6, and both of these hosts use a shared home directory. Using the exact same set of keys with the exact same permissions, I can connect from the RHEL4 client to a RHEL3 client which does NOT use the shared home directory. – joshxdr Jan 27 '11 at 23:07
  • I tried changing the permissions on authorized_keys to 0600 as suggested by others. This did not work. User jack still cannot connect without password. – joshxdr Jan 27 '11 at 23:20
  • 4
    I found the answer. It was in the permissions of the home directory of user jack. User jack had group write permissions on the home directory, while jane did not. – joshxdr Jan 27 '11 at 23:31
  • You said "new RHEL4 box". Did you mean RHEL5? 4 is pretty ancient at this point... – Jason Antman Jan 28 '11 at 02:15
  • 1
    You should post that comment as an answer, and then accept that, so others know your question is answered and what the answer is. – Josh Jan 28 '11 at 03:11

4 Answers4

6

I found the answer. It was in the permissions of the home directory of user jack. User jack had group write permissions on the home directory, while jane did not. The problem is that all of the tutorials on the web specify the permissions for the .ssh directory and the files, but fail to mention that the user directory itself needs to have write permission for group turned off.

joshxdr
  • 257
  • 3
  • 15
3

Have you tried restricting the permission of the .ssh directory? Because in most cases that would work. Not sure though where that "strict" configuration is but I encountered the same issue several times before and changing permissions on the .ssh directory fixed the problem.

Josh
  • 9,190
  • 28
  • 80
  • 128
icasimpan
  • 616
  • 3
  • 6
  • 15
2

I had the same problem, but with a user ssh'ing to another user local to the same system.

All permissions the same with both users.

Experimentation showed that users A and B could log in as each other, but neither could connect as user C.

It turned out that user C (being a system user) didn't have a shadow entry although he did have a passwd entry.

Hopefully this will be helpful to someone with the same problem later on.

System: OpenIndiana oi_151a

Thor Sigurdsson
  • 21
  • 1
0

I use CentOS which is actually RHEL. I found myself in the situation that the SELinux contect of the .ssh directory/files was wrong.

Check the /var/log/audit/audit.log for details about SELiunx activities.

Gerhard
  • 86
  • 5