LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices

Reply
 
Search this Thread
Old 10-14-2005, 09:52 AM   #1
flgal3
LQ Newbie
 
Registered: Aug 2005
Distribution: RedHat Enterprise WS v.3
Posts: 27

Rep: Reputation: 15
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.)
 
Old 10-14-2005, 10:26 AM   #2
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
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.

Last edited by Quigi; 10-14-2005 at 10:31 AM.
 
Old 10-14-2005, 11:08 AM   #3
TruckStuff
Member
 
Registered: Apr 2002
Posts: 498

Rep: Reputation: 30
Quote:
Originally posted by Quigi
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.
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).
Quote:
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.
What does "shared on both clients" mean, specifically?
 
Old 10-14-2005, 01:12 PM   #4
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
Quote:
Originally posted by TruckStuff
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.
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.
Quote:
What does "shared on both clients" mean, specifically?
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.
 
Old 10-14-2005, 01:18 PM   #5
flgal3
LQ Newbie
 
Registered: Aug 2005
Distribution: RedHat Enterprise WS v.3
Posts: 27

Original Poster
Rep: Reputation: 15
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 . . .
 
Old 10-14-2005, 02:18 PM   #6
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
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
Code:
/usr/sbin/sshd -dd -p 2222 -h ~/.ssh/id_rsa -f /dev/null
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.
 
Old 10-14-2005, 02:34 PM   #7
flgal3
LQ Newbie
 
Registered: Aug 2005
Distribution: RedHat Enterprise WS v.3
Posts: 27

Original Poster
Rep: Reputation: 15
Quote:
Originally posted by Quigi
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.
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
 
Old 10-14-2005, 03:56 PM   #8
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
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.
Quote:
Originally posted by flgal3
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 [/B]
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:
Code:
debug1: userauth-request for user brech service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for brech
debug1: Starting up PAM with username "brech"
debug1: PAM setting rhost to "oxygen.xxx.xxx"
debug2: input_userauth_request: try method none
Failed none for brech from 192.168.1.xx port 41251 ssh2
debug1: userauth-request for user brech service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 508/515 (e=508)
debug1: trying public key file /home/brech/.ssh/authorized_keys
debug1: matching key found: file /home/brech/.ssh/authorized_keys, line 4
Found matching RSA key: 5e:d3:15:72:fe:14:38:62:84:f3:9c:5d:f2:fc:xx:8c
debug1: restore_uid
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for brech from 192.168.1.xx port 41251 ssh2
debug1: userauth-request for user brech service ssh-connection method publickey
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method publickey
debug1: temporarily_use_uid: 508/515 (e=508)
debug1: trying public key file /home/brech/.ssh/authorized_keys
debug1: matching key found: file /home/brech/.ssh/authorized_keys, line 4
Found matching RSA key: 5e:d3:15:72:fe:14:38:62:84:f3:9c:5d:f2:fc:xx:8c
debug1: restore_uid
debug1: ssh_rsa_verify: signature correct
debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa
PAM rejected by account configuration[13]: User account has expired
Failed publickey for brech from 192.168.1.xx port 41251 ssh2
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.
 
Old 10-14-2005, 04:05 PM   #9
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
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.)
 
Old 10-14-2005, 04:22 PM   #10
flgal3
LQ Newbie
 
Registered: Aug 2005
Distribution: RedHat Enterprise WS v.3
Posts: 27

Original Poster
Rep: Reputation: 15
Quote:
Originally posted by Quigi
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.
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!
 
Old 10-14-2005, 04:25 PM   #11
anomie
Senior Member
 
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora, Lubuntu, FreeBSD
Posts: 3,930
Blog Entries: 5

Rep: Reputation: Disabled
OP:

What does
Code:
grep 'AuthorizedKeysFile' /etc/ssh/sshd_config
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.

Last edited by anomie; 10-14-2005 at 04:29 PM.
 
Old 10-14-2005, 07:14 PM   #12
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
I guess you'll get this Monday.

Quote:
Originally posted by flgal3
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.
[/B]
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.
 
Old 10-19-2005, 02:15 PM   #13
flgal3
LQ Newbie
 
Registered: Aug 2005
Distribution: RedHat Enterprise WS v.3
Posts: 27

Original Poster
Rep: Reputation: 15
Talking 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!!!!
 
Old 09-19-2006, 03:39 PM   #14
forrie
Member
 
Registered: Sep 2003
Distribution: RedHat
Posts: 37

Rep: Reputation: 15
Lightbulb 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.
 
Old 09-19-2006, 04:05 PM   #15
Quigi
Member
 
Registered: Mar 2003
Location: Cambridge, MA, USA
Distribution: Ubuntu (Dapper and Heron)
Posts: 377

Rep: Reputation: 31
Quote:
Originally Posted by forrie
the permissions on ~/.ssh/authorized_keys must be 0600 on Linux -- or it won't work.
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., ~.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh public key authentication teacup Linux - Networking 4 11-27-2011 11:27 PM
DISCUSSION: Public key authentication with ssh david_ross LinuxAnswers Discussion 31 02-02-2011 08:13 AM
SSH - Problem with Public Key Authentication HaPagan Linux - Security 5 11-28-2005 11:27 PM
ssh public key authentication to different remote home directory shawn_t Linux - Networking 2 03-20-2005 03:39 PM
SSH public/private key authentication with GnuPG keys? thinksincode Linux - Security 1 02-25-2005 02:33 PM


All times are GMT -5. The time now is 10:56 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration