web-dev-qa-db-ja.com

authorized_keysで許可が拒否されました

Chrootされたユーザー用にSFTPをセットアップし、SSH公開鍵認証を使用しようとしています。この例では、「sftpusers」のメンバーであるダミーユーザー「globocorp」を使用します。このユーザーは/ sftp/globocorpにchrootされています

公開鍵を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）。パケットを読み取れませんでした：接続がピアによってリセットされました」と表示されます。

linuxsecurityauthenticationsftpchroot
1
esoterydactyl

わかった！

このサイトの指示に従ってください： http://sysadmin.circularvale.com/server-config/rsa-authentication-with-chrooted-sftp-authorized_keys-location/

ルートとして、次の場所に別のフォルダーを作成しました。

 /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された場所に置くことができます。これは、chrootがログイン後まで処理されないためです。権限は上記のとおりである必要があります-他の権限は機能しませんでした。 （親ディレクトリでは700ではありません）sshd_configで定義されたパスは絶対パスです（/ =サーバーの/であり、ユーザーのchrootではありません！）

これをデバッグするために、このコマンドを使用して、別のポート（23）でsshdを実行し、既存のセッションを中断しませんでした。

/usr/sbin/sshd -d -p 23

次に、リモートサーバーからSFTP経由で接続を試みました。これにより、サーバー側は、ログイン試行で何が起こっているのかを明確に説明する有用なデバッグメッセージを出力しました。

3
esoterydactyl

debug1：許可されたキーを開けませんでした '/sftp/globocorp/sftpdirectory/.ssh/authorized_keys'：許可が拒否されました

UID/GID 559/506を持つユーザーが、パス/sftp/globocorp/sftpdirectory/内のすべてのディレクトリに対して少なくともトラバース（実行）権限を持っていることを確認してください。そうでない場合は、それを追加します。

1
user9517