我正在尝试为chroot用户设置SFTP，并使用SSH公钥authentication。 在这个例子中，我将与“sftpusers”的成员dummy用户“globocorp”。 这个用户被chrooted到/ sftp / globocorp
我把我的公钥放在我的sshd_config中指定的位置：/sftp/globocorp/sftpdirectory/.ssh/authorized_keys
当远程用户通过命令行SFTP尝试连接到服务器时，会在服务器端logging此消息：
debug1: trying public key file /sftpdirectory/.ssh/authorized_keys debug1: Could not open authorized keys '/sftpdirectory/globocorp/.ssh/authorized_keys': Permission denied 我已经审查了权限和build议 – 执行这些命令：
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（服务器端）完整的debugging信息如下：
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）。无法读取数据包：
我知道了！
按照本网站上的说明操作： http : //sysadmin.circularvale.com/server-config/rsa-authentication-with-chrooted-sftp-authorized_keys-location/
作为根，我创build了一个单独的文件夹：
/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用户的authorized_keys可以位于用户被chroot out的位置。 这是因为chroot在login之后才被处理。 权限应该完全如上所述 – 没有其他权限的工作。 （父目录不是700）在sshd_config中定义的path是绝对的（/ =服务器的/，而不是用户的chroot！）
为了debugging这个，我使用这个命令在一个单独的端口（23）上运行sshd，而不是中断现有的会话：
/usr/sbin/sshd -d -p 23
然后尝试通过SFTP从远程服务器进行连接。 这导致服务器端输出有用的debugging消息，清楚地解释了我的login尝试发生了什么。
debug1：无法打开授权密钥'/sftp/globocorp/sftpdirectory/.ssh/authorized_keys'：权限被拒绝
检查具有UID / GID 559/506的用户是否至less遍历（执行）了path/sftp/globocorp/sftpdirectory/所有目录的权限。 如果他们没有，然后添加它。