私はシステム管理者です。運用環境では、何千ものサーバーを管理する必要があります。同僚と私は中央管理サーバーを使用し、他のサーバーを通じてその公開鍵を配布しています。したがって、この管理サーバーを使用して、他のサーバーにSSH接続できます。
場合によっては、ルートパスワードを使用する必要があります。たとえば、サーバーがダウンしている場合は、iLOを使用して理由を特定する必要があります。
現在、共有rootパスワードを使用しています。安全ではありません。私はOPIE
(One-time Passwords In Everything)のような単一サーバーソリューションも検討しましたが、サーバーが非常に多いため、これはあまり良い考えではありません。
編集:
パスワード管理ソリューションに欲しいのは:
そのため、既知のコマンド(openssl passwd
など)から生成されますが、rootパスワードを長いランダムな文字列に設定することはあまりお勧めできません。覚えるのが難しく、時々生成するのが難しい(私のラップトップなしでは)
常に無効なパスワードを設定することもできます。これにより、rootへのネットワークアクセスが妨げられ、シングルユーザーモードで起動すると、ほとんどのディストリビューションはシェルから直接起動します。
これはおそらくあなたが思っているほどセキュリティ上の問題ではありません。とにかくrootパスワードをバイパスするのは簡単です。パスワードでgrubをロックダウンしない限り、ほとんどの場合、initrdではなくbashを開始するようにgrubに指示することができます。
もちろんこれは、代わりにブートローダーをパスワードで保護する方法を考えるべきであることを意味するかもしれません。
一元管理でワンタイムパスワードを使用できます。これは、「ethがオフラインで、サーバーがiLOでアクセスされているときに動作する必要がある」には当てはまりません。
とにかく、問題は、サーバーがオフラインになる頻度です。
したがって、次の設定を考えることができます。
Privacyidea( http://www.privacyidea.org )のような集中管理されたOTPソリューションを使用します。いくつかの異なるOTPトークンをrootユーザーに割り当てることができます。各トークンには異なるOTP PINがあり、異なるデバイスです。したがって、すべての同僚はユーザーrootとしてログインできますが、監査ログでは認証されたトークンが表示されるため、どの同僚がログインしたかを知ることができますその時に。
サーバーで、認証リクエストをRADIUSとprivacyIDEAに渡すようにpam_radiusを設定する必要があります。
残念。これでサーバーがオフラインになります。この場合、あなたはあなたのpamスタックで遊ぶべきです。私は次のようなものを考えることができます:
auth sufficient pam_unix.so
auth required pam_radius.so use_first_pass
固定パスワードでオフラインでログインできるようにします。そうしないと、パスワードがpam_radiusに渡され、privacyIDEAに対してOTPとして検証されます。
このハウツー https://www.howtoforge.com/manage-two-factor-authentication-in-your-serverfarm-with-privacyidea を参照してください。