Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to set up SSH host keys from our Mac OS X 10.5 Leopard Server-based central backup server to our two Linux servers running Fedora 10 and CentOS 5.2. The process we usually take works and puts the key in ~/.ssh/authorized_keys, but it still prompts for the password.

I'm not the regular admin of these boxes and I understand the default is probably to have SSH host keys disabled. How do enable SSH host keys?

Update: I had already uncommented 'PubkeyAuthentication yes' in /etc/ssh/ssd_config and ran service restart sshd, but that didn't work. Uncommented all three lines ('RSAAuthentication', 'PubkeyAuthentication', and 'AuthorizedKeysFile'), corrected permissions on ~/.ssh and tried again. Still no love.

When I run ssh -v user@host I get the following before it prompts for a password and after some GSS errors:

debug1: Next authentication method: publickey
debug1: Trying private key: /Users/shortname/.ssh/identity
debug1: Trying private key: /Users/shortname/.ssh/id_rsa
debug1: Trying private key: /Users/shortname/.ssh/id_dsa
debug1: Next authentication method: password

Further suggestions?

Another Update: Permissions on ~/ and ~/.ssh/ are 700.

The command I've been running to create the host key is as follows:

cat /blah/ssh_keys_for_shortname/id_dsa.pub | ssh -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld 'cat - >> ~/.ssh/authorized_keys'

And when attempting to connect I use:

ssh --verbose -l shortname -o stricthostkeychecking=no -i /blah/ssh_keys_for_shortname/id_dsa host.domain.tld

So, obviously we're using DSA keys. I've tried renaming ~/.ssh/authorized_keys2, but that doesn't help.

I'd love to store the keys in their default locations instead of /blah/ssh_keys_for_shortname/, but it's out of my control.

When I watch /var/log/audit/audit.log and try to connect, I get the following:

type=CRED_DISP msg=audit(1249426114.642:128): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:setcred acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_END msg=audit(1249426114.647:129): user pid=10589 uid=0 auid=501 ses=14 msg='op=PAM:session_close acct="shortname" exe="/usr/sbin/sshd" (hostname=host.domain.tld, addr=192.168.1.149, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1249426129.524:130): user pid=10633 uid=0 auid=4294967295 ses=4294967295 msg='acct="shortname": exe="/usr/sbin/sshd" (hostname=?, addr=192.168.1.149, terminal=sshd res=failed)'

Suggestions?

share|improve this question
add comment

5 Answers 5

up vote 7 down vote accepted

Looks like you have the basics correct.

The most common reason I've seen for this to fail is the permissions on the remote authorized_keys file and the directories above it. Before allowing key-based auth, sshd performs a permissions check; if it doesn't like the results, it disallows authentication. I generally set ~/.ssh to 0700 and ~/.ssh/authorized_keys to 0600. I believe the actual $HOME cannot have group or world write either, although reading is fine.

If that still doesn't fix it, the next step is to do some debugging on the server side:

server$ /usr/sbin/sshd -d -p 2222

Then connect to the "debug" server from your client:

client$ ssh -v user@host  -p 2222

You will get copious debugging informtation on stderr on the server. I have yet to encounter an auth problem I couldn't track down from there.

share|improve this answer
    
Hmmm... I see you say you've already fixed the perms on authorized_keys. Can you paste the output of "ls -ld ~user" and "ls -lR ~user/.ssh"? –  Insyte Aug 3 '09 at 22:26
    
My coworker ran into this same issue again on another project last weekend and was able to resolve it w/mode 0700 on ~/.ssh, mode 0600 on ~/.ssh/authorized_keys and a chmod go-w ~/. IIRC, the home folder was already mode 0755 so I'm not sure why removing group/other write access changed anything, but it did resolve the issue. Finally! I'm going to mark your answer as the solution. –  morgant May 27 '10 at 18:39
add comment

Here's the process I would follow.

  1. Create public/private key pair on the OS X server. I do not specify a passphrase when prompted.

    $ ssh-keygen -b 4096 -C "myusername@myhostname" -t rsa

  2. Copy the contents of ~/.ssh/id_rsa.pub on the OS X server to ~/ssh/authorized_keys in the correct user's home directory on the CentOS/Fedora hosts.

  3. Verify the permissions are correct on all the hosts. The directory ~/.ssh should be mode 0700, the files inside should be 0600 (You can use 0644 for the public keys, but it doesn't hurt to be more restrictive).

If the key-based authentication is not working yet, verify that the following values are set in your sshd_config file (/etc/ssh/sshd_config) on each of the CentOS/Fedora hosts. (These values should be defaults.)

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

If it still doesn't work, try ssh -v user@host to see what is happening when you connect. Add more v's to see more details about what's happening.

EDIT: Try verifying the permissions on the full directory tree from / to the .ssh directory in question. If any one of the directories in that path are group or world writable, SSH will bomb out. Run this to print out the permissions of all the directories in the path:

j="" ; for i in `echo ~baumgart/.ssh | sed 's%/% %g'` ; do ls -ld $j/$i ; j=$j/$i ; done

Also - check the logfile for messages from sshd on the CentOS/Fedora systems - That should have a useful message about what's wrong. It should be in /var/log/messages or /var/log/auth.log. If you can't find it, do grep sshd /var/log/*.

share|improve this answer
1  
Instead of directly editing ~/ssh/authorized_keys on the remote host, one can use the the ssh-copy-id script that comes with most Linux distros. I haven't used the script from OSX, but it is pretty simple and should work. It doesn't check for duplicate entries. –  Not Now Aug 3 '09 at 20:27
add comment

If you've already set the user/group permissions properly, you may be running into SELinux issues. The easiest way to fix this is with restorecon -R /home/user/.ssh/. The errors will be logged in /var/log/audit/audit.log and you can use the audit2why tool to have the system explain any SELinux denials that may have occurred.

share|improve this answer
    
Thanks. I remember we ran into some SELinux issues in the past and the regular admin of that box said he had disabled it. I ran the restorecon command anyway and watched /var/log/audit/audit.log and saw no errors while attempting to log in (everything said "success"). I'll keep digging. –  morgant Aug 4 '09 at 22:35
    
The sestatus command will tell you if you've got SELinux enforcing/permissive/disabled. It's typically best to leave it in Permissive when you're debugging something since you'll get the denials documented but your actions will be allowed to succeed just like if it was disabled. –  Ophidian Aug 5 '09 at 15:04
    
sestatus returns "SELinux status: disabled". –  morgant Aug 6 '09 at 20:51
    
Thanks, this was my problem. –  El Yobo Oct 1 '11 at 2:14
add comment

'PubkeyAuthentication yes' in /etc/ssh/sshd_config ?

share|improve this answer
add comment

The first thing to point out is that the /var/log/audit.log is logging SELinux activity.

I'm guessing if you look a little further back in that log, you'll see another entry that looks something like this:

type=AVC msg=audit(xxxxxxxxx.xxx:xxxx): avc: denied { search } for pid=xxxxx comm="sshd" name="xxxxxx" dev=xxxx ino=xxxxxx scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

What this means is that your sshd process is confined by the loaded selinux policy and is not able to accessing the file system path in which your authorized keys file is sitting.

To verify that the selinux policy is active, run the sestatus command and you'll see the following output:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

To quickly test whether this is the problem or not, you can temporarily set SELinux into permissive mode by issues the setenforce permissive command. After you do so, run sestatus again and you should see the following output:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

Try your ssh connection again, and given that all of your other configuration is correct, it should work.

Moving forward, you should probably create custom rules which allow access to the path you're after, but that is beyond the scope of this help.

To make this change persistent (survive reboots), you need to modify the /etc/selinux/config file and change:

SELINUX=enforcing

to

SELINUX=permissive
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.