對授權密鑰的權限被拒絕
我正在嘗試為 chroot 使用者設置 SFTP，並使用 SSH 公鑰身份驗證。在本例中，我將使用虛擬使用者“globocorp”，他是“sftpusers”的成員。此使用者已 chroot 到 /sftp/globocorp
我已將我的公鑰放在我的 sshd_config 中指定的位置：/sftp/globocorp/sftpdirectory/.ssh/authorized_keys
當遠端使用者嘗試通過命令行 SFTP 連接到伺服器時，伺服器端會記錄此消息：
debug1: trying public key file /sftpdirectory/.ssh/authorized_keys debug1: Could not open authorized keys '/sftpdirectory/globocorp/.ssh/authorized_keys': Permission denied我已經查看了權限和建議 - 執行了這些命令：
chown globocorp:sftpusers /sftpdirectory/globocorp/.ssh chmod 700 /sftpdirectory/globocorp/.ssh chmod 600 /sftpdirectory/globocorp/.ssh/authorized_keys.ssh 文件夾上的 ls -l 輸出如下所示：
drwx------ 2 globocorp sftpusers 4.0K Nov 3 15:04 .ssh和個人文件：
-rw------- 1 globocorp sftpusers 406 Nov 3 12:13 authorized_keys來自 sshd（伺服器端）的完整調試資訊如下：
debug1: sshd version OpenSSH_5.3p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Bind to port 22 on ::. Server listening on :: port 22. Generating 1024 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.102.109 port 38946 debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_5.3 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 aes128-ctr hmac-md5 none 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 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 globocorp service ssh-connection method none debug1: attempt 0 failures 0 debug1: user globocorp matched 'User globocorp' at line 150 debug1: user globocorp matched group list sftpusers at line 158 debug1: PAM: initializing for "globocorp" debug1: PAM: setting PAM_RHOST to "192.168.102.109" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user globocorp service ssh-connection method publickey debug1: attempt 1 failures 0 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 559/506 (e=0/0) debug1: trying public key file /sftp/globocorp/sftpdirectory/.ssh/authorized_keys debug1: Could not open authorized keys '/sftp/globocorp/sftpdirectory/.ssh/authorized_keys': Permission denied debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 559/506 (e=0/0) debug1: trying public key file /sftp/globocorp/sftpdirectory/.ssh/authorized_keys debug1: Could not open authorized keys '/sftp/globocorp/sftpdirectory/.ssh/authorized_keys': Permission denied debug1: restore_uid: 0/0 Failed publickey for globocorp from 192.168.1.19 port 38946 ssh2 Connection closed by 192.168.1.19 debug1: do_cleanup debug1: do_cleanup debug1: PAM: cleanup背景資訊：
SELinux 已禁用。
CentOS 6.5
執行 OpenSSH_5.3p1
SFTP -vv 輸出只是說：“權限被拒絕（公鑰，gssapi-keyex，gssapi-with-mic）。無法讀取數據包：對等方重置連接”
我得到了它！
按照本網站上的說明：http: //sysadmin.circularvale.com/server-config/rsa-authentication-with-chrooted-sftp-authorized_keys-location/
作為 root，我在以下位置創建了一個單獨的文件夾：
/usr/local/share/keys/globocorp/.ssh/該文件夾歸root所有，權限設置為“755”
。authorized_keys文件在該文件夾中，歸使用者所有，權限設置為600。
sshd_config 包含這一行：
AuthorizedKeysFile /usr/local/share/keys/%u/.ssh/authorized_keys而這個匹配塊：
Match user globocorp ChrootDirectory /sftp/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE -f LOCAL6 PubkeyAuthentication yes PasswordAuthentication yes總而言之：
chroot 使用者的授權密鑰可以位於使用者被 chroot 的位置。這是因為 chroot 直到登錄後才被處理。權限應該與上述完全一致——沒有其他權限起作用。（父目錄上不是 700） sshd_config 中定義的路徑是絕對的（/ = 伺服器的 /，而不是使用者的 chroot！）
為了調試它，我使用這個命令在一個單獨的埠（23）上執行 sshd 並且不中斷現有會話：
/usr/sbin/sshd -d -p 23然後嘗試從遠端伺服器通過 SFTP 連接。這導致伺服器端輸出有用的調試消息，清楚地解釋了我的登錄嘗試發生了什麼。