OpenSSH は、2 つのシステム間に安全で暗号化された接続を作成します。一方のマシンが他方のマシンを認証してアクセスを許可します。認証は、マシン自体のサーバー接続に対するものである場合と、該当マシン上のユーザーに対する場合があります。OpenSSH の詳細は、12章OpenSSH で説明されています。

この認証は、認証を行なっているユーザーもしくはマシンを特定する 公開キーと秘密キーのペア を通して実行されます。マシンにアクセスしようとしているリモートのマシンもしくはユーザーは、キーのペアを提示します。するとローカルマシンは、そのリモートのエンティティを信頼するかどうかを決定します。信頼できる場合は、そのリモートマシン用の公開キーは known_hosts ファイルに、リモートユーザー用の公開キーは authorized_keys ファイルに保存されます。このリモートマシンもしくはユーザーが再度認証を試みる際は常に、ローカルシステムは単にこの known_hosts か authorized_keys ファイルを最初にチェックして、このリモートのエンティティが認証され、信頼できるものかを確かめた後にアクセスを許可します。

最初の問題は、これらの ID 認証を信頼性を持って行うことです。

known_hosts ファイルは、マシン名、IP アドレス、公開キーの 3 つで構成されています。

server.example.com,255.255.255.255 ssh-rsa AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776=

known_hosts ファイルは、様々な理由ですぐに古いものとなってしまいます。IP アドレス経由の DHCP サイクルを使用しているシステムでは、新たなキーが定期的に再発行されたり、仮想マシンやサービスがオンラインで持ち込まれたり削除されたりする場合があります。このようなことがあると、ホスト名、IP アドレス、キーの構成が変わってしまいます。

管理者は、現行の known_hosts ファイルをクリーンに維持して、セキュリティーを保つ必要があります。 (さもなくば、システムユーザーは、単に提示されたマシンやキーをどれでもうけいれるという習慣に陥ってしまい、キーベースのセキュリティーの利点がなくなってしまいます。)

さらには、マシンとユーザーにはスケーラブルな方法でキーを配布するという問題があります。マシンは暗号化セッション確立の一部としてキーを送信できますが、ユーザーは事前にキーを提供する必要があります。単にキーを伝達し、一貫してアップデートするのは、困難な管理タスクです。

最後に、SSH キーおよびマシン情報はローカルでのみ維持されます。known_hostsファイルが一様にアップデートされていないと、ネットワーク上のマシンやユーザーが一部のシステムには認識、信頼され、別のシステムには認識、信頼されないということが起こり得ます。

SSSD のゴールは、認証情報キャッシュとして機能することです。これには、マシンおよびユーザーの SSH 公開キーの認証情報キャッシュとして機能することが含まれます。OpenSSH は、キャッシュされたキーの確認に SSSD を参照するように設定されています。SSSD は、 Red Hat Linux の Identity Management (IPA) ドメインを ID として使用し、Identity Management は実際に公開キーおよびホスト情報を保存します。

sss_ssh_knownhostsproxy [-d sssd_domain] [-p ssh_port] HOST [PROXY_COMMAND]

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p -d IPA1 %h
UserKnownHostsFile2 .ssh/sss_known_hosts

sss_ssh_authorizedkeys [-d sssd_domain] USER