web-dev-qa-db-ja.com

公開鍵認証は、sshdがデーモンの場合にのみ失敗します

これがどのようにして起こるのか、私には手がかりがありません。ディストリビューションはScientific Linux 6.1であり、すべてが公開鍵を介して認証を実行するように設定されています。ただし、sshdがデーモンとして実行されている場合（サービスsshd start）、公開鍵は受け入れられません。 （このログを取得するために、sshdスクリプトを変更して-dddオプションを追加しました）

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Sshdがデバッグモードで実行されている場合/usr/sbin/sshd -ddd、認証は魅力のように機能します：

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

何か案は？？このようなものを見たことがありますか？

ノート：

ファイルのアクセス許可が再確認されました：

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Sshdが「デーモンモード」でrootのファイルにアクセスできるかどうか尋ねられました。この質問に最も近い答えは次のとおりです。

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Sshdがrootとして実行されている場合、自分のファイルにアクセスできないのかわかりません。 SELinuxが原因でしょうか？

linuxsshauthenticationdaemonkeys
33
user666412

はい、SELinuxが原因である可能性があります。 .ssh dirのラベルが誤っている可能性があります。 /var/log/audit/audit.logを見てください。 ssh_home_tというラベルが付いているはずです。 ls -laZで確認してください。必要に応じてrestorecon -r -vv /root/.sshを実行します。

43
Mark Wagner

同じ問題がありました。私の場合、restoreconとchconが機能しませんでした。

Selinuxを無効にしたくありませんでした。多くの調査の結果、ホームディレクトリが他の場所（NFS）からマウントされたことが原因であることがわかりました。 このバグレポート が見つかりました。

私が走った：

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

use_nfs_home_dirsがオフになっていることを確認してから：

Sudo setsebool -P use_nfs_home_dirs 1

をつけるために。

これで、キーを使用して、パスワードを入力せずにマシンにsshできます。 use_home_nfs_dirsブール値を切り替えることが、私に必要なことでした。

3
Gerard

Mark Wagnerの回答に追加するには、カスタムホームディレクトリパス（つまり、/homeではない）を使用している場合、SELinuxセキュリティコンテキストを設定していることを確認する必要があります。これを行うには、たとえば/myhomeにユーザーのホームディレクトリがある場合、次のコマンドを実行します。

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome
1
DavidArndt

接続をテストするときに、0x7f266e1a8840と0x7f85527ef230の異なるキーを使用しているようです。 'ssh -v example.com'を使用して、デーモンとしてデバッグモードで実行されているsshdに接続し、「Offering RSA public key」という文字列の周りでsshが使用するキーを探します。

0
Johan Nilsson