12

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?

8 Answers 8

9

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.

3
  • 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, 2011 at 16:36
  • Thank you! chmod g-w ~/ saved me after hours of madness and hair pulling when I could not ssh with putty on behalf of one of users, with other users working ok...
    – PavelS
    Aug 19, 2015 at 11:12
  • Gah ya thanks, I created my home directory with my other user, and I was missing chmod g-w ~/ Jan 18, 2016 at 14:53
5

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.

4
  • 1
    Hmm, that's more of a workaround than a solution, though. Let me check something on my box.
    – Rob
    Dec 8, 2011 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, 2011 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, 2011 at 20:13
  • This way is userless!
    – Love
    Mar 19, 2017 at 5:37
3

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.

2

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.

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

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.

1

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

restorecon -FRvv ~/.ssh

(from this answer)

0
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 {} \;
1
  • 3
    Welcome to Super User! It'd be nice if you could explain what these commands do.
    – slhck
    May 21, 2013 at 4:49
0

In my case it was the home directory which had another owner (root) than the actual user to which this home directory belongs to (my stupidity when creating the home dir with root for another user).

Chown [user]:[group] /home/[user] 

has solved this issue (and of course stick to the file/dir permissions as shared in other answers).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .