Mar*_*jon 6 ssh authentication rsa
我在 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 服务器没有将该设置设为“否”。
我真的被难住了，大约一个星期以来，我一直试图在获得许可的情况下解决问题。希望有人以我的方式提出一些想法。
我只是有完全相同的情况：（bad ownership on /xxx顶部文件夹）。
在我的情况下，所有其他常见的 ssh 要求都得到满足：
w”去任何地方（团体或其他人）.ssh.ssh/authorized_keys然而，一个sshd -d会话始终显示
Authentication refused: bad ownership or modes for directory /xxx
我发现的唯一差异是/xxx/yyy由拥有root，而/xxx由“ aUser”拥有。
我做root了chown root:root /xxx
错误消失了。
| 归档时间： |
|
| 查看次数： |
12313 次 |
| 最近记录： |