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

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.

share|improve this question
    
Two identical, almost word-for-word answers posted within seconds of eachother. I think you might have found your answer ;) –  Mark Henderson Nov 1 '12 at 0: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 1 '12 at 0:13

2 Answers 2

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.

share|improve this answer
    
By "Fix", what should the setting be? The current setting is 755, and this is the same setting for the other two servers. –  Marjon Nov 1 '12 at 0:12
    
The correct permissions are 0700. –  daff Nov 1 '12 at 0:15
    
Thanks daff, did that, still the same error though. –  Marjon Nov 1 '12 at 0:20

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
share|improve this answer
    
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 1 '12 at 0:11
    
I don't think it should be world-anything. So chmod o= /root should fix you up. –  Michael Hampton Nov 1 '12 at 0:13
    
I have changed it to 700, still the same error though. No go. :( –  Marjon Nov 1 '12 at 0:19
1  
So what does the debug log say now? –  Michael Hampton Nov 1 '12 at 0: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 1 '12 at 0:28

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.