ssh public key authentication problem
 

I've searched the forums for an answer to this, but nothing I've found remedies the problem.

In our network, home directories are shared among Redhat boxes via NFS. I would like to be able to ssh from one machine to another without having to enter a password. The goal is to be able to use rdist or rsync. But, I can notget past this basic ssh problem.

I've followed all the instruction to use ssh-keygen -t dsa and create pub/private keys on the client I wish to connect from. Then I copy or cat the id_dsa.pub file into authorized_keys. All the files are located in ~/.ssh which is of course shared on both the clients. And yet whenever I ssh from the client to another machine, it always asks for the password. ARGH!! snipets from the ssh verbose output are below.

Thank you in advance!

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kdonate/.ssh/identity
debug1: Trying private key: /home/kdonate/.ssh/id_rsa
debug1: Offering public key: /home/kdonate/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

(at which point it now asks me for the password.)

From the -vv output you posted, all seems fine locally.

Check ownership and permission of ~/.ssh/* both locally and remotely. Use "ls -l" and "ls -ln".

Specifically, if you haven't taken an effort to align user ids on both computers, they are probably different. If you are locally user id 501, and on the other computer user 501 is Joe (but you are 502), then he "owns" your .ssh/ on the other machine. (File ownership goes by user ID, also across NFS mounts; whether that's the same person or someone else on another machine seeing the same volume.)

To debug further, you may want to run sshd in debug mode on the remote machine. It will only service 1 connection then exit, but that should be enough (or you start it again). You can run it as a normal user, listening on a high port like 2222; no need to shut down the normal sshd (by root on :22) then. (It won't be able to read /etc/shadow, but when password authentication kicks in, you already know publickey didn't work.) From the local machine, "ssh remote -p 2222 -vv" to connect to it.

That's only relevant if you were to copy everything from one ocmputer to the other as root and force cp to preserve UIDs, which is a really stupid thing to do.

Start by tailing /var/log/secure or /var/log/messages to find out what SSHD is complaining about. Verify that your authorized keys file is ~/.ssh/authorized_keys (check your sshd config file). What does "shared on both clients" mean, specifically?

I disagree. It is also relevant if you share directories via NFS. Which flgal3 does. Supid or not, that's how NFS works. Probably you should have your user IDs aligned when using NFS.
Presumably that several RedHat boxes mount the same homedirectory over the network.
(Even one mount from host A to B could raise issue.) We've had a setup like that across the whole lab. It works, but it takes discipline. Actually the whole department had centralized rules; each lab was assinged a slice of 100 user ids (e.g., 3200..3299) and 10 group ids that they could assign their users.

ssh public key authentication problem in NFS/NIS env
 

Ah, I forgot to mention that we are using NIS to manage the UIDs. So, that eliminates the potential for different user accounts on the two machines. Let me try the sshd debug suggestion . . .

I concur with TruckStuff's suggestion to look in /var/log/{messages,secure} first. If it has enough detail to tell you what's wrong, it's the easiest.

To run sshd in debug mode, you could type
I give an empty configuration file (/dev/null) because RedHat normally makes the default, /etc/ssh/sshd_config, only readable for root. (If you read the man page you see that that's NOT recommended. It can be readable, it just mustn't be writable by anyone except root.)
The private host keys, /etc/ssh/host{,_dsa,_rsa}_key must not be readable to normal users. That's why I supply my own private rsa key as the "host" key using the -h option.
Note that the port number must be >= 1024 for a normal user, and the one you pick (e.g., 2222) must not be blocked by a local firewall like iptables.

That is it exactly, we use NIS, NFS, and the automounter on our systems. Regardless of what system a user logs into they use the same password and will have the same home directory on any machine. The output from running sshd in debug below is below. It is easy to see were is failed reading the authorized_keys file, but I'm not sure why. The file is owed by the user/group combo 507/501. Read permissions are clearly available for the owner and group. Oh, and yes, the file does exist in the location it is looking for.

debug1: userauth-request for user kdonate service ssh-connection method none
debug1: attempt 0 failures 0
debug1: Starting up PAM with username "user1"
Failed none for user1 from 192.xxx.xx.xx port 40059 ssh2
debug1: userauth-request for user user1 service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM setting rhost to "hostA.domian.com"
debug1: temporarily_use_uid: 507/501 (e=0/0)
debug1: trying public key file /home/user1/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 507/501 (e=0/0)
debug1: trying public key file /home/user1/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for kdonate from 192.xxx.xx.xx port 40059 ssh2
debug1: userauth-request for user user1 service ssh-connection method keyboard-interactive
debug1: attempt 2 failures 2

Odd. I cannot see what's going wrong. Are you sure the file authorized_keys is NOT writable by anyone besides user1? I recall that ssh distrusts a (group or other) writable authorized_keys file.
From the restore_uid I gather you're running the sshd as root. That should even take care of some PAM problems that I see, though they are unrelated. Here's what I get:
I'm missing lines like the bold section in your output. Sorry, I can't see what's wrong. Probably something real easy. Tell me and I'll slap my forehead :)
BTW, the account has not expired. PAM just fails because it's not root. If I run sshd as root, brech gets in, without a password.

P.S: stat (or ls -lu) /home/user1/.ssh/authorized_keys to see if sshd even opened it and was unsatisfied by the content, or if it was put off by some external attribute like permissions. If the former, is the last line terminated with a newline? (If you copied the file, you have the newline, and it's not the issue.)

I agree the lines in bold are the exact ones that are missing. Yes, I did run sshd as root, 'coz, I guess, I could. ;-)

There is something interesting in the secure log file that may help:


Oct 14 09:26:46 hostA sshd[7158]: Authentication refused: bad ownership or modes for directory /home/user1

I'll have to experiment with the group and public read/write permissions on the .ssh dir and its files. *Mostly* of the docs I found said to do use 700 on the dir and 600 on the files. Yet, I did find one thread or doc somewhere that said to have read permission on both group and public when using NFS to automount the home directory.

Well - its 5:00 somewhere, on a Friday too! I think I'll hit this again on Monday. Thank you sooooo much for your help. At least I can stop banging my head against the wall. (For now.)

Have a great weekend!

OP:

What does on the sshd server machine show you?

I would first make sure that the keys file is named what you think it is.

edit: The debug reporting seems to indicate that it is looking for the correct file, but does not find it. Permissions problem seems pretty likely.

I guess you'll get this Monday.

Hey, that's it! TruckStuff sent you on the right track all along.

Complaint is about the home directory, which I'd make 755, though Linux default is 700.
Normally .ssh is 700 too. Not sure if 755 would hurt; it shouldn't. Just don't let anyone write!
Files can be 644, except the private keys, like id_dsa, which MUST be 600. But ssh-keygen does all this correctly by itself.

Does NFS mount do something weird about permissions? E.g., I could imagine a read-only flag on the mount, which shouldn't cause youre trouble, but is there something more exotic? Just a wild guess.

what a difference a weekend makes
 

Thank you all so much for your suggestions and very helpful hints. I can't say exactly what I changed, but the ssh sessions are now password free. I'm made sure that the user home dir is 755 as is the ~/.ssh. The public keys files and the authorization file are 644. The private key files are 600.

While debugging some other issues on the systems, I cleaned up a bunch of things regarding my /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow file. I can't help but to wonder if that may have improved the situation as well.

Regardsless, I can now move onto step two using rsync or rdist in a cron job to keep distributed files in sync.

Thanks again!!!!

authorized_keys issues
 

For what it's worth, I ran into this problem today whilst trying to perform automated login from FreeBSD -> Linux (CentOS and Redhat AS).

After pulling many hairs...

The problem ended up being simple: the permissions on ~/.ssh/authorized_keys must be 0600 on Linux -- or it won't work.

Oddly, this doesn't affect FreeBSD-6.1 - and I'm not sure where that's configured in the build.

Good luck.

In many flavors of Linux, it doesn't have to be 0600. In CentOS release 4.2 (Final), 0644 works just fine.

Sshd (rightly) refuses to log in if authorized_keys is writable by others. This also applies to containing directories, e.g., ~.