selinuxがパスワードなしでリモートsshアクセスをブロックするのはなぜですか？
CentOS 7サーバーを持っています。パスワードなしでログインしようとしているホストに/root/.ssh/authorized_keysを設定しました。 （はい、リモートルートアクセスを許可することは悪い考えですが、これは内部サーバーです。）sshが失敗し、selinux監査ログにこれがあります。
type=USER_LOGIN msg=audit(1494544798.597:481313): pid=18660 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=xx.xx.xx.xx terminal=ssh res=failed'
.sshの権限とコンテキストは次のとおりです。
# ls -aZ /root/.ssh
drwx------. root root system_u:object_r:ssh_home_t:s0 .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root system_u:object_r:ssh_home_t:s0 authorized_keys
-rw-r--r--. root root unconfined_u:object_r:ssh_home_t:s0 known_hosts
アクセス許可とコンテキストを、パスワードなしでsshログインを許可する別のシステムのものと比較しましたが、それらは同じです。
監査メッセージには、selinuxが心配しているファイルが示されておらず、「res = fail」のみです。
動作するシステムでは、ログエントリに次のように記述されています。
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
だから、私は混乱しています。 /root/.sshには、コンテキストsystem_u：system_r：sshd_tを持つファイルはありません。そのため、そのコンテキストがログに記録される理由がわかりません。
すべての.ssh関連ファイルのコンテキストがどうあるべきかを知る方法はありますか？はい、私は運が悪くてrestoreconで遊んだことがあります。
SELinuxにすぐにジャンプします... sshを介したrootアクセスを許可するように/ etc/ssh/sshd_configが適切に設定されていますか？構成ファイルに変更を加えた場合は、sshdサービスを再始動しましたか。
SELinuxを寛容に設定してこれをテストしてみましたか？.
SELinuxがアクセスを拒否していた場合、/ var/log/audit/audit.logにある種のAVC（Access Vector Cache）エラーが表示されると思います。 audit.logは、SELinuxの問題以外にも使用されることに注意してください。したがって、得られるのは単にログイン失敗レポートであり、SELinuxエラーではありません。
あなたが持っている公開/秘密のopensshキーペアが実際にsshコンテキストで機能することを本当に確信していますか？ -vオプションを指定したsshコマンドを使用してログを記録し、これをデバッグして確認できます。
詳細については、/ var/log/messagesおよび/ var/log/secureファイルもチェックします。
この問題には短い 記事 があります。それは言う
sELinuxコンテキストが.sshフォルダーと承認済みキーファイルに正しく設定されていないことが原因である可能性があります[...]これを修正する方法は、実行することです
# restorecon -R -v /root/.ssh
この記事では、最初から正しく権限を設定する方法も示しています。
# chmod 755 /root/.ssh/
# chmod 600 /root/.ssh/authorized_keys
# restorecon -R -v /root/.ssh
私のVPSでは私が持っているので、最初のコマンドに関する記事には同意しませんが
# chmod 700 /root/.ssh/
私の個人的な経験から、ssh-key認証についていくつかの重要なことを学びました。
- OpenSSHの新しいバージョン（OpenSSH 7.0で始まった私の問題）がある場合、「ssh-dssホストおよびユーザーキーのサポートは実行時にデフォルトで無効になっている」ため、DSAキーは機能しません。解決策は、RSAキーを使用するか、リモートマシンで
PubkeyAcceptedKeyTypes=+ssh-dssを/etc/ssh/sshd_configに追加し、クライアントマシンで~/.ssh/configに追加することです。 - クライアント側での問題のデバッグは、オプション
-vvvvvをssh呼び出しssh -vvvvvv [email protected]に追加することで実行できます。 - サーバー側での問題のデバッグは、
/etc/ssh/sshd_configを編集することで実行できます。
SyslogFacility AUTH
LogLevel DEBUG
（オプションのヘルプは# man sshd_configで入手できます）
次に、ssh接続中に/var/log/debugを確認します。デバッグログが見つからない場合は、/var/log/messagesおよび/var/log/secureを確認してください（最後の手段として、/etc/syslog.confの設定を確認してください）。
restorecon -R -v ~/.sshが機能せず、SELinuxがsealertまたはaudit2allowレポートごとに責任がある場合、および。sshフォルダーのSELinuxコンテキストが以下を変更すると、キーベースの認証でのログオンの問題を修正できます。
$ Sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ Sudo restorecon -FRv /path/to/my/.ssh
この修正は、以下に示す種類のAVCが確認された場合に有効でした。
$ Sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
私の場合は調べていました
root＃> journalctl -f
次に、SELinuxに、nfsホームディレクトリへの使用が許可されることを伝えます。
root＃> setsebool -P use_nfs_home_dirs 1
これは私の問題を解決します。
私はCentOS 7でこの問題を抱えていました。私は通常のDebianベースのLinuxユーザーなので、水面下の魚でした。一部のサーバーでは機能し、一部のサーバーでは機能しないことに気付きました。 audit.logは何も役に立たないと述べ、secure.logも何も与えませんでした。唯一の本当の違いは、ファイルとディレクトリのセキュリティコンテキストの違いが、機能するものと機能しないものとの間であることがわかりました。セキュリティを確保する
Sudo ls -laZ <user-home>/.ssh
ディレクトリの（私はsshd_configの多くのデフォルトを想定しています）。
いくつかのssh_home_tおよびuser_home_t属性。そうでない場合は、chconコマンドを使用して、不足している属性を追加します。
例えば：
home="$(getent passwd <user> | cut -d: -f6)"
Sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home/.ssh"
Sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"
私の場合、私の疑いは、ユーザーが非標準的な方法で作成されたことです。彼の家は/var/lib。