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

We have some scripts that need to rsync without entering a password. I am trying to SSH to a local machine (itself). I cannot get it to work. It is always asking me for a password. It works fine SSH-ing to a remote machine.

I am running CentOS 6. The user's home directory is in a non-standard location (i.e. it is not under /home/$USER).

Here is what I have done to try and get this working.

I created private key using

ssh-keygen -t rsa -C "servername.domain" 

without a passphrase.

copied the generated public key to ~/.ssh/authorized_keys and tried to SSH using

ssh servername.domain

and it is asking me for a password. I have tried playing with permissions of that file to no avail.

I have noticed that when I SSH using a password I get this error in the /var/log/secure log file. Not sure if this is related, but the error is as below.

Feb 12 09:15:34 servername unix_chkpwd[14652]: password check failed for user 

When performing ssh -v and comparing the results of a seesion that working without prompting for a password (remote) and one that always prompts (local) I can see a few difference. The first is that the failure shows:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context

Whereas the working session shows just the first line, the following two are not present.

Later I see:

debug1: Offering public key: /myuser/.ssh/id_rsa

On the working version this is followed by:

debug1: Server accepts key: pkalg ssh-rsa blen 277

Whereas on the failing versiodn it is followed by:

debug1: Trying private key: /myuser/.ssh/id_dsa
debug1: Next authentication method: password

I have since found that SSH works when disabling selinux. I think the issue may be due to the non-standard location of the user's home directory.

share|improve this question
    
Try using 'ssh -v servername.domain' to enable detailed error message. –  Tutul Feb 12 at 12:17
1  
Your sshd might be configured in a way users' .ssh directory is not searched for authorized_keys. You should check your sshd_config file as well. –  Ouki Feb 12 at 12:20
    
@Ouki I've put debug on in the sshd config and can see that it is looking in the correct directory –  bledi Feb 12 at 12:38
    
@Tutul I have added output from working and failing examples. –  bledi Feb 12 at 12:44
1  
Also, you say you've verified that sshd is looking in the right place for authorized_keys, which is great: but you haven't shown us the evidence. –  MadHatter Feb 12 at 13:31

1 Answer 1

When you use keys, if the perms on the .ssh directory and/or the authorized_keys files are not correct then ssh falls back to passwords if it is allowed to do so (PasswordAuthentication Yes).

Check that the permissions on ~./ssh are 700 and that the ~/.ssh/authorized_keys perms are 644 (or tighter).


As you've identified SElinux as causing the problem and you've said that the user home directory is located in a non standard location then check /var/log/audit/audit.log for relevant AVC denied messages.

You could also try relabelling the relevant directory tree

semanage fcontext -a -t user_home_t "/path/to/homedir(/.*)?"
restorecon -r /path/to/homedir
share|improve this answer
    
Yes, the permissions are correct (700 and 600) –  bledi Feb 12 at 12:59

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.