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


33

私はこれがどのように起こるのか見当もつかない。ディストリビューションはScientific Linux 6.1であり、すべてが公開鍵を介して認証を実行するように設定されています。ただし、sshdがデーモンとして実行されている場合(サービスsshdの開始)、公開鍵は受け入れられません。(このログを取得するために、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が「デーモンモード」でルートのファイルにアクセスできるかどうかを尋ねられました。この質問に最も近い答えは次のとおりです。

# 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が原因でしょうか?


1
sshd initスクリプトは何か面白いことをしますか?(/etc/init.d/sshdになりますか?)コマンドラインで実行していませんか?「service sshd start」の代わりに「sh -x /etc/init.d/ssh start」を試してください。
PT

回答:


42

はい、SELinuxが原因である可能性があります。.sshDIRはおそらく誤表示されます。見てください/var/log/audit/audit.log。ラベルを付ける必要がありますssh_home_t。で確認してくださいls -laZrestorecon -r -vv /root/.ssh必要に応じて実行します。


1
はい、SELinuxが原因でした:type = AVC msg = audit(1318597097.413:5447):avc:denied {read} for pid = 19849 comm = "sshd" name = "authorized_keys" dev = dm-0 ino = 262398 scontext = unconfined_u :system_r:sshd_t:s0-s0:c0.c1023 tcontext = unconfined_u:object_r:admin_home_t:s0 tclass = file「restorecon -r -vv /root/.ssh」を実行すると動作します。どうもありがとう。
user666412

1
おかげでselinuxコマンドラインの修正に感謝しますsshキー認証を使用してredhatエンタープライズ6.2サーバーのルートとしてsshできる理由を長年探していましたが、非rootユーザーとしてsshでログインできませんでしたパスワードを入力する必要はありません。「ssh -v」は、異常を示すものではありませんでした。/home/example/.sshのファイル保護を確認し、再確認しました。「/ usr / sbin / sshd -d」を実行するまで、他の何かが発生していることに気づいたのは、何らかの理由で正常に機能していました。別のGoogle検索を試してみて、これを見つけました。だから、症状は私がROとしてsshでできた
ポール・M

1
ファイルシステム全体、つまりrestorecon -r /YMMVでこれを行う必要がありました。
Irfy 14年

1
私はこれを試しましたが、まだ動作していません。私が持っている監査ログtype=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir-それが何を意味するのかわからない
-Yehosef

1
答えはname="/"-にありました- restorecon -r /@Irfyが示唆したとおりに実行しなければなりませんでした。
エホセフ

3

同じ問題がありました。私の場合、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ブール値の切り替えは、私にとって必要なことでした。


1

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

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

あなたはCentOSのにしている場合は、あなたが得るためにこれを実行する必要がありますsemanagesudo yum install policycoreutils-python
sm4rk0

0

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


はい、id_rsaとid_dsaがありました。DSAキーがなくなり、テストをやり直します。
user666412

に記載されている値はdebug3: mm_answer_keyallowed: key 0xFFFFFFFFFF、sshdが新しい接続を受信するたびに変わります。これを確認するには、SSHが動作するサーバーを見つけ、sshd LOGLEVELをdebug3に上げ、sshdを再起動し、実行tail -f /var/log/secure |grep mm_answer_keyallowedしてから数回ログインし、各接続間で数秒(または数分)待機します。値は毎回変わることがわかります。そして実際には、私にとってはカウンターのように見えます。
ステファンLasiewski
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.