Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have the same exact problem described in this thread, but the answer accepted there is not the right one for me, because the user's home directory is local.

I think that I configured everything properly on the client side (Windows 7, PuTTY's PAGEANT, PUTTYGEN and PLINK), yet I don't seem to make the public key mechanism work (password based ssh login works). I followed all the steps, cues and hints in:

I now suspect that I may be missing something on the server side (Linux, sshd), so I am posting the current /etc/ssh/sshd_config content:

Protocol 2
SyslogFacility AUTHPRIV
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Any idea what I am doing wrong?

UPDATE: I found a tip for running sshd in debug mode, and here is the output:

/home/winwin> /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.2p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.8 port 49828
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60
debug1: no match: PuTTY_Release_0.60
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done

debug1: userauth-request for user winwin service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "winwin"
debug1: PAM: setting PAM_RHOST to "win7client"
debug1: PAM: setting PAM_TTY to "ssh"
Failed none for winwin from 192.168.1.8 port 49828 ssh2
debug1: userauth-request for user winwin service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 513/513 (e=0/0)
debug1: trying public key file /home/winwin/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/winwin
debug1: restore_uid: 0/0
Failed publickey for winwin from 192.168.1.8 port 49828 ssh2
Received disconnect from 192.168.1.8: 14: No supported authentication methods available
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

Now, I do notice the two bad ownership or modes for directory /home/winwin messages but I checked the ownership or modes for directory /home/winwin and AFAICT they're OK:

/home> ls -lad winwin
drwxrwxr-x  21 winwin winwin 4096 Jul 13 21:24 winwin

And:

/home/winwin> ls -lad .ssh
drwxr-xr-x  2 winwin winwin 4096 Jul 14 12:06 .ssh

And:

/home/winwin/.ssh> ls -lad *
-rw-r--r--  1 winwin winwin 210 Jul 14 12:06 authorized_keys
-rw-r--r--  1 winwin winwin 210 Jul 14 01:58 authorized_keys.pub
-rw-r--r--  1 winwin winwin 394 Jul 14 01:57 authorized_keys.pub.orig

What could possibly be wrong?

UPDATE II: I tried chmod 600 as suggested in the answer below:

/home/winwin> ls -lad .ssh
drw-------  2 winwin winwin 4096 Jul 14 13:13 .ssh

And:

/home/winwin/.ssh> ls -lad *
-rw-------  1 winwin winwin 210 Jul 14 12:06 authorized_keys

But it still doesn't work. Why am I still getting the Authentication refused: bad ownership or modes for directory /home/winwin error?

share|improve this question

7 Answers 7

Try taking the group writeable permissions from your home directory:

chmod g-w ~/

Make your .ssh folder readable/writeable/executable only by you:

chmod 700 ~/.ssh

Make your authorized keys file readable/writeable only by you:

chmod 600 ~/.ssh/authorized_keys

That should remove the permissions errors.

share|improve this answer
    
I did just as you suggested for ~/.ssh and ~/.ssh/authorized_keys. Still no luck. As for taking the group writeable permissions from the home directory itself, I can't do that as it would undermine the entire purpose of this user/group has been created for. The home directory of this user must be writeable by the group (having same exact name and gid!). +1 for attempting to help. –  WinWin Jul 14 '11 at 16:36
up vote 3 down vote accepted

Success!

All I had to do is change StrictModes to no.

Per section 3.14 in the OpenSSH FAQ and http://blogs.nullvision.com/?p=114 .

Wow.

share|improve this answer
    
Hmm, that's more of a workaround than a solution, though. Let me check something on my box. –  Rob Dec 8 '11 at 20:10
    
My ls -lad .ssh is showing drwx, so chmod 700 ~/.ssh and the files inside are all -rw, so chmod 600 ~/.ssh/* -SHOULD- work. –  Rob Dec 8 '11 at 20:12
    
Nevermind, saw The home directory of this user must be writeable by the group (having same exact name and gid!) below –  Rob Dec 8 '11 at 20:13

Had a similar issue. When poking around I noticed that I had my home directories encrypted, and suspected that was the issue. I copied the authorized keys file to a directory outside of the encrypted home directory, changed the permissions appropriately (chmod 700 [dir], chmod 600 [dir]/authorized_keys, etc.).

Then edit your sshd_config to tell sshd of the new location for the authorized keys file, restart sshd, and that's it.

Seems to have fixed my problem.

share|improve this answer

It looks like your permissions for the home directory (or possibly your .ssh/authorized_keys folder) are incorrect. Correcting those should fix the login issue. Try chmod 600 /home/winwin/.ssh/*
You might need to chmod 700 /home/winwin/.ssh as well.

SSHd will refuse to load your authorized_keys file if it can be written to by anyone other than your user (as the owner) because it's a security risk.

share|improve this answer
    
Thanks +1. See my update above, as I still can't figure out what the correct permissions/ownership should be. –  WinWin Jul 14 '11 at 15:44
    
I just tried chmod 600 /home/winwin/.ssh/*. It didn't help. :-/ –  WinWin Jul 14 '11 at 15:49
1  
@WinWin did you set it on the .ssh directory as well? (I updated my answer). –  Darth Android Jul 14 '11 at 15:52
    
Yes, I did. Still no luck. –  WinWin Jul 14 '11 at 15:58

I struggled through this and finally found a solution which doesn't cause a potential security breach like StrictModes No does.

Make sure your settings are as follows:

chmod 0755 /home/{userdir}

chmod 0700 /home/{userdir}/.ssh

chmod 0600 /home/{userdir}/.ssh/authorized_keys

Where {userdir} is the directory in question.

The key is chmod 0755 which ensures that only the user can write to the home drive. I copied this from my user config that worked, and, presto! The other usernames started working too!

Hope this helps others like it did me, and saves you a couple hours of time.

share|improve this answer
chown -R winwin.winwin /home/winwin/
chmod 700 /home/winwin/
find /home/winwin/ -type d -exec chmod 700 {} \;
find /home/winwin/ -type f -exec chmod 600 {} \;
share|improve this answer
3  
Welcome to Super User! It'd be nice if you could explain what these commands do. –  slhck May 21 '13 at 4:49
    
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. –  Rhys Gibson May 21 '13 at 5:31

This error message can also be caused by SELinux preventing sshd from accessing authorized_keys. Try this:

restorecon -FRvv ~/.ssh

(from this answer)

share|improve this answer

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.