6

I am running a Linux version 2.6.27-vpac2 on a PXA270 platform (armv5tel) I have a version of OpenSSH 3.8.1 p1 (Debian-8.sarge.4) trying to get to run on it. I have run the sshd in -ddd format to debug and below is the result when I try to connect:

  root@thisslave:~/.ssh$ /usr/sbin/sshd -ddd -f /etc/ssh/sshd_config
  debug2: read_server_config: filename /etc/ssh/sshd_config
  debug1: sshd version OpenSSH_3.8.1p1 Debian-8.sarge.4
  debug1: private host key: #0 type 0 RSA1
  debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
  debug1: read PEM private key done: type RSA
  debug1: private host key: #1 type 1 RSA
  debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
  debug1: read PEM private key done: type DSA
  debug1: private host key: #2 type 2 DSA
  debug1: Bind to port 22 on 0.0.0.0.
  Server listening on 0.0.0.0 port 22.
  socket: Address family not supported by protocol
  debug1: Server will not fork when running in debugging mode.
  Connection from 192.168.1.101 port 40520
  debug1: Client protocol version 2.0; client software version OpenSSH_5.8p1 Debian-7ubuntu1
  debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH*
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
  debug1: list_hostkey_types: ssh-rsa,ssh-dss
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
  debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
  debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
  debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
  debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
  debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
  debug2: kex_parse_kexinit: none,zlib
  debug2: kex_parse_kexinit: none,zlib
  debug2: kex_parse_kexinit: 
  debug2: kex_parse_kexinit: 
  debug2: kex_parse_kexinit: first_kex_follows 0 
  debug2: kex_parse_kexinit: reserved 0 
  debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
  debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
  debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
  debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
  debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
  debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
  debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
  debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
  debug2: kex_parse_kexinit: 
  debug2: kex_parse_kexinit: 
  debug2: kex_parse_kexinit: first_kex_follows 0 
  debug2: kex_parse_kexinit: reserved 0 
  debug2: mac_init: found hmac-md5
  debug1: kex: client->server aes128-ctr hmac-md5 none
  debug2: mac_init: found hmac-md5
  debug1: kex: server->client aes128-ctr hmac-md5 none
  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
  debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
  debug2: dh_gen_key: priv key bits set: 134/256
  debug2: bits set: 518/1024
  debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
  debug2: bits set: 538/1024
  debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
  debug2: kex_derive_keys
  debug2: set_newkeys: mode 1
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug2: set_newkeys: mode 0
  debug1: SSH2_MSG_NEWKEYS received
  debug1: KEX done
  debug1: userauth-request for user root service ssh-connection method none
  debug1: attempt 0 failures 0
  debug2: input_userauth_request: setting up authctxt for root
  debug2: input_userauth_request: try method none
  Failed none for root from 192.168.1.101 port 40520 ssh2
  debug1: userauth-request for user root service ssh-connection method publickey
  debug1: attempt 1 failures 1
  debug2: input_userauth_request: try method publickey
  debug1: test whether pkalg/pkblob are acceptable
  debug1: temporarily_use_uid: 0/0 (e=0/0)
  debug1: trying public key file /root/.ssh/authorized_keys
  debug3: secure_filename: checking '/root/.ssh'
  debug3: secure_filename: checking '/root'
  Authentication refused: bad ownership or modes for directory /root
  debug1: restore_uid: 0/0
  debug1: temporarily_use_uid: 0/0 (e=0/0)
  debug1: trying public key file /root/.ssh/authorized_keys
  debug3: secure_filename: checking '/root/.ssh'
  debug3: secure_filename: checking '/root'
  Authentication refused: bad ownership or modes for directory /root
  debug1: restore_uid: 0/0
  debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
  Failed publickey for root from 192.168.1.101 port 40520 ssh2
  debug1: userauth-request for user root service ssh-connection method keyboard-interactive
  debug1: attempt 2 failures 2
  debug2: input_userauth_request: try method keyboard-interactive
  debug1: keyboard-interactive devs 
  debug1: auth2_challenge: user=root devs=
  debug1: kbdint_alloc: devices 'pam'
  debug2: auth2_challenge_start: devices pam
  debug2: kbdint_next_device: devices <empty>
  debug1: auth2_challenge_start: trying authentication method 'pam'
  debug3: PAM: sshpam_init_ctx entering
  Failed keyboard-interactive for root from 192.168.1.101 port 40520 ssh2
  Connection closed by 192.168.1.101
  debug1: do_cleanup

A few things to note:

1) I am using keys which is currently being used in two other servers (of the same platform and linux kernel build)

2) I have set the permissions accordingly for the .ssh directory (700), authorized_keys (644). For the server, I think these are the ones needed, please correct me if I am wrong.

3) If I turn off the StrictMode setting (i.e. set to 'no'). I am able to connect. But I believe that's something I shouldn't do, because the two other sshd servers running does not have that setting to 'no'.

I am really stumped and been trying to work things out with the permission for about a week now. Hoping for someone to throw some ideas my way.

Marjon
  • 71
  • 1
  • 1
  • 3
  • Two identical, almost word-for-word answers posted within seconds of eachother. I think you might have found your answer ;) – Mark Henderson Nov 01 '12 at 00:01
  • Mark, I did think it had something to do with the /root folder setting, but I am not sure to what extent I should limit access to it? The other two servers running, have the same setting for the /root directory (755). – Marjon Nov 01 '12 at 00:13

4 Answers4

9

I just had the exact same case: bad ownership on /xxx (the top folder).

All the other usual ssh requirements were met in my case:

  • no 'w' for go anywhere (group or others)
  • 700 for .ssh
  • 600 for .ssh/authorized_keys

And yet, an sshd -d session consistently shown 

Authentication refused: bad ownership or modes for directory /xxx

The only discrepency I found is that /xxx/yyy was own by root, while /xxx was owned by "aUser".

I did as root a chown root:root /xxx

And the error went away.

VonC
  • 2,683
  • 5
  • 30
  • 49
8

What about the message that is displayed twice in the debug logs:

Authentication refused: bad ownership or modes for directory /root

Fix the permissions of /root and see where that takes you.

daff
  • 4,809
  • 2
  • 28
  • 27
4

The problem was printed in your log:

  Authentication refused: bad ownership or modes for directory /root

Check the permissions of the root user's home directory, /root.

An example of working permissions from a live server:

error@www ~ $ ls -ld /root
drwx------. 6 root root 4096 Oct 16 19:12 /root
Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • I have checked /root, and permissions are set to 755 for the /root directory. It is the same for the other sshd servers running. What should the correct setting for /root? – Marjon Nov 01 '12 at 00:11
  • I don't think it should be world-anything. So `chmod o= /root` should fix you up. – Michael Hampton Nov 01 '12 at 00:13
  • I have changed it to 700, still the same error though. No go. :( – Marjon Nov 01 '12 at 00:19
  • 1
    So what does the debug log say _now_? – Michael Hampton Nov 01 '12 at 00:20
  • It was the same thing after I changed the permissions. But I tried to resend the key again using *ssh-copy-id*. It spit out the same "Authentication refused: bad ownership or modes for directory /root", but further down the debug lines, I get "Failed publickey for root from 192.168.1.101 port 41605 ssh2". – Marjon Nov 01 '12 at 00:28
  • If you actually login successfully (with your password) while running `ssh-copy-id` then it should fix any broken permissions for you. – Michael Hampton Nov 01 '12 at 00:33
  • I found a solution, but it's very weird. I created another user, created a /home/ home directory, **logged in** using this new user, logged out. And re-run (or reboot system, since sshd is part of the boot up script) sshd, then I could login as normal. Weird! – Marjon Nov 01 '12 at 02:04
  • @Marjon : The permissions of the home dir itself are important (with sshd_config StrictMode(s) ON at least): 755 should work. You probably re-created with these default permissions but they were likely more open before. – Patrice M. Jan 02 '15 at 02:50
3

A more comprehensive answer is found on this blog post: http://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

The TL;DR version of it is (the permissions are fairly specific):

chmod go-w /home/your-user
chmod 700  /home/your-user/.ssh
chmod 600  /home/your-user/.ssh/authorized_keys*

Additionally, if your user's home dir is a symlink, you want to follow it and chmod go-w / chmod 755 to that as well.

Patrice M.
  • 213
  • 1
  • 7