I'm unable to ssh without a password for some reason on a new CentOS box.

I've tried following these guides:

But neither are working. I even checked my /etc/ssh/sshd_config file. PubkeyAuthentication yes was originally commented out so I uncommented that line and restarted sshd but still to no avail. Any thoughts of anything else that could be missing?

I'm trying to ssh from server A to server B as root. Thus, logged in as root on one box, then ssh to the next as root without being prompted for a password.


I ran a ssh -v ... but cannot copy/paste into here. Everything looked good until this line:

debug1: Next authentication method:  gssapi-with-mic
debug1: Unspecified GSS failure.  Minor Code may provide more information
Unknown code krb5 195
  • ssh from where to where using what key? – 84104 Feb 16 '12 at 0:22
  • What is the output of ssh -v ... when you try to connect? – Zoredache Feb 16 '12 at 0:36
  • See my edit above.... – Wild Bill Feb 16 '12 at 0:42
  • Over at the Ubuntu forums there was a thread that suggested it was because of a OpenSSH vulnerability - and the fix appears to be regenerating your server keys. – Mei Feb 16 '12 at 1:15
  • 2
    Also make sure your .ssh subdirectory has permissions of 700. – Mei Feb 16 '12 at 1:19

A small how-to for public key based authentication for CentOS/Red Hat/etc...

On the SSH client:

ssh-keygen # Accept all defaults, do not enter a password.
ssh-copy-id USER@SERVER_IP
restorecon -R ~/.ssh

On the SSH server:

# Login to the server normally (with password)
restorecon -R ~/.ssh

Public key based authentication should now work.

  • Accepting this one as the answer, though it wasn't what was needed to solve the issue. Point at SERVER_IP is what lead me to the issue at hand. My /etc/hosts file had the fully qualified name of the server despite the hostname of the machine not actually containing the domainname. Additionally the domain name was not set on the machine but rather the domain name is used for DNS. Modifying the entry in /etc/hosts corrected the issue. Thanks all to helped and let this hopefully help folks in the future. – Wild Bill Feb 24 '12 at 0:37

These problems (which are usually permissions related) are much more easily debugged from the server side. I recommend that you start another sshd in debug mode with: /usr/sbin/sshd -d -p 2222 which will start another sshd on port 2222, then run ssh -p 2222 user@sshserver on the client side. Watch what comes out of the sshd when your client tries to authenticate.

Permissions problems don't have to be just /home/$USER/.ssh. it could also be a problem with /, /home, or /home/$USER. If any of those are group writable it can be a problem.

Another common problem is that you mis-paste and put linebreaks in the middle of your key in the authorized_keys file

serverA# ls -lah /root
serverA# ls -lah /root/.ssh
serverA# selinuxenabled 
serverA# echo $?

serverB# ls -lah /root
serverB# ls -lah /root/.ssh
serverB# senlinuxenabled
serverB# echo $?

If that doesn't show you the problem, try the following. ServerA is the client and serverB the ssh server.

On serverB, edit /etc/ssh/sshd_config. Find the line that looks like:

LogLevel INFO

Change it to:



serverB# /etc/init.d/sshd restart

On serverA:

serverA# ssh -vvv root@serverb

You can now reivew the /var/log/secure file on serverB for clues.

As a final tip, please review:



Check your permissions, they should be


for your .ssh directory and


for your authorized_keys file.

So, to set the permissions properly, try this:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If you have SELinux enabled, then this is a common problem...

Run the following on the SSH server:

restorecon -R /home/$USER/.ssh

or, for root:

restorecon -R /root/.ssh

'Nuff Said...

  • That did not work. I'm still being prompted for a password. – Wild Bill Feb 16 '12 at 0:32
  • Where did you run the command? Server or client? Hint: Run it on both. – Soviero Feb 16 '12 at 0:33
  • I ran it on both. – Wild Bill Feb 16 '12 at 0:34
  • See my other answer... – Soviero Feb 16 '12 at 0:40

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.