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=, 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=, 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=, terminal=sshd res=failed)'


5 Answers 5


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.

  • 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, 2009 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, 2010 at 18:39
  • Same difficulties on my fedora system. Removing the group write permissions on the home directory finally solved the problem.
    – Spacemoose
    Sep 28, 2016 at 12:02

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

  • 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, 2009 at 20:27

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.

  • 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, 2009 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, 2009 at 15:04
  • sestatus returns "SELinux status: disabled".
    – morgant
    Aug 6, 2009 at 20:51

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:




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

  • Just setting up a new Debian 10 server having uploaded my public SSH keys and logging in without password, done all the recommended edits in /etc/ssh/sshd_config - but wondering if #PubkeyAuthentication yes commented out means "no setting" i.e. I can still log in pw-free without explicitly uncommenting this, as some posts seem to indicate? Probably should be a new question… Mar 14, 2021 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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