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

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?

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 ?