我正在尝试为 chrooted 用户设置 SFTP，并使用 SSH 公钥身份验证。在此示例中，我将与虚拟用户“globocorp”合作，他是“sftpusers”的成员。此用户 chrooted 到 /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 输出仅显示：“权限被拒绝（publickey、gssapi-keyex、gssapi-with-mic）。无法读取数据包：对等方重置连接”
答案1
我得到了它！
按照此网站上的说明进行操作： 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
因此，总而言之：
chrooted 用户的 authorized_keys 可以位于用户被 chroot 出的位置。这是因为 chroot 直到登录后才会处理。权限应与上面描述的完全一致 - 任何其他权限均无效。（父目录上的权限不是 700）sshd_config 中定义的路径是绝对的（/ = 服务器的 /，而不是用户的 chroot！）
为了调试这个问题，我使用此命令在单独的端口（23）上运行 sshd 并且不中断现有会话：
/usr/sbin/sshd -d -p 23
然后尝试通过 SFTP 从远程服务器进行连接。这导致服务器端输出有用的调试消息，清楚地解释了我登录尝试时发生的情况。
答案2
debug1：无法打开授权密钥'/sftp/globocorp/sftpdirectory/.ssh/authorized_keys'：权限被拒绝
检查 UID/GID 为 559/506 的用户是否至少对路径中的所有目录具有遍历（执行）权限/sftp/globocorp/sftpdirectory/。如果没有，则添加它。