OpenSSH 伺服器身份驗證被拒絕

我在 PXA270 平台 (armv5tel) 上執行 Linux 版本 2.6.27-vpac2 我有一個版本的 OpenSSH 3.8.1 p1 (Debian-8.sarge.4) 試圖在它上面執行。我已經以 -ddd 格式執行 sshd 進行調試，下面是我嘗試連接時的結果：

 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

需要注意的幾點：

1）我正在使用目前在其他兩台伺服器（相同平台和 linux 核心版本）中使用的密鑰

2. 我已經為 .ssh 目錄 (700)、authorized_keys (644) 設置了相應的權限。對於伺服器，我認為這些是需要的，如果我錯了，請糾正我。

3. 如果我關閉 StrictMode 設置（即設置為“否”）。我能夠連接。但我認為這是我不應該做的事情，因為另外兩個正在執行的 sshd 伺服器沒有將該設置設置為“否”。

我真的很難過，並且在獲得許可的情況下已經嘗試了大約一周的時間。希望有人以我的方式提出一些想法。

調試日誌中顯示兩次的消息怎麼樣：

身份驗證被拒絕：目錄/root 的所有權或模式不正確

修復權限/root並查看它會將您帶到哪裡。

我剛剛遇到了完全相同的情況：（bad ownership on /xxx頂部文件夾）。

在我的案例中，所有其他常見的 ssh 要求都得到了滿足：

• 沒有’ w‘去任何地方（組或其他人）
• 700 為.ssh
• 600 為.ssh/authorized_keys

然而，一個sshd -d會話始終顯示

Authentication refused: bad ownership or modes for directory /xxx

我發現的唯一差異是/xxx/yyy由擁有root，而/xxx由“ aUser”擁有。

我做了root一個chown root:root /xxx

錯誤消失了。

引用自：https://serverfault.com/questions/444234