How to allow SSH host keys on Linux (Fedora 10 & CentOS 5.2)

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.

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/*.

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.

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

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