SSH authentication anomalities

[exec22]

I have a master management server that is trusted by every other system in our data center via ssh keys.

I know it is insecure but we use the same authorized key on every single server and it works fine. It allows us to access other servers without having to type a passphrase or password.

There is this new server that I installed sshd Ver 4.20 and this server, has the same authorized keys file with the same ownership and permissions. .ssh directory ownership and permissions are the same with some other servers that I compared this one to. Yet, the other servers do not ask me to enter my root password when I am accessing to those via ssh, but this new one does. Other servers run sshd Ver 3.81 and I am wondering if there are any authentication differences between these two versions. I checked the sshd_config file between a normal working server and this non-working one and found them to be the same as far as the effective lines go (ones which are not commented out) I noticed in both sides PermitRootLogin yes line was commented out and I was wondering if the default behavior has been reverted or what ?

Thank you.

[Ken Grabowski]

I am using 4.20 on 11iv1 and 11iv2. Default is "PermitRootLogin yes" so line does not require to be uncommitted.

Check to make sure you have the correct permissions. An .ssh dir should be 700 or 755 and authorized_keys should be 755. Wrong permissions will cause it to fail.

I did have a problem when I tryed to set up a user with a non-standard home directory. Never did resolve that. But I have root using /root and ordinary users using /home/logname with no problems.

[Denver Osborn]

Is there anything helpful in the syslog.log? On the client if you use "ssh -vvv" for verbose logging it might help troubleshoot. You could also start and instance of sshd with deubugging. Chances are it's a problem w/ the keys or authorized_keys file.. or permissions.

To rule out the config, generate a seperate public/private keypair and put the public key on the new servers ~/.ssh/authorized_keys file, then try connecting using that new key... (i.e. ssh -vvv -i your_new_key -o PreferredAuthentications=publickey hostname)

If this new key works, look closer at the authorized keys file entry and/or permissions.

hope this helps,

-denver