回答:
ほとんどの場合、リモートrootログインを実際に無効にしてもほとんどメリットはありません。これは、管理者が自分のアカウントを使用してログインしsu、必要に応じてroot化する（または、ポリシーに応じsudoてsudosh...を使用する）ポリシーを実施するのに役立ちます。
非常に長くて扱いにくいルートパスワードを作成する（パスワードに古代のDES + 12-ビットソルトハッシュをまだ使用していない限り効果的です）と、このようなポリシーを適用するのとほぼ同じくらい効果的です。
私がよく知っている1つのサイトには、ホストごとに一意のパスワードがランダムに生成され、データベースに格納され、システムに送信されるシステムがありました。管理者はssh、通常のアカウントで、sudoほとんどの操作で使用する必要がありました。ただし、ルートパスワードは、SSLベースの内部Webサービスを介してアクセスできました（さらに、RSA SecurIDトークンとPINが必要でした）。ルートパスワードを取得するには、正当な理由（通常はRemedy（TM）チケット番号へのリンク）と定期的に監査される場所へのアクセスを入力する必要がありました。rootパスワードを直接使用するいくつかの許容できる理由の1つは、fsck起動プロセス中にシステムが停止した場合でした...およびsuloginファイルシステムのチェックと修復プロセスを手動で実行するために、実際のrootパスワードが必要でした。（これの代替方法についていくつかの議論がありました-これはLinuxで比較的簡単ですが、多くのレガシーHP-UX、AIX、および古いSunOSおよびSolarisシステムに対応するように手順を拡張しようとすると、はるかに難しくなります。その環境ではまだ本番環境にありました）。
rootパスワードが必要な場合があります---または少なくとも利用可能な最良の代替手段です。予想できる種類の脅威に対して十分に堅牢にする一方で、それを利用可能にしておくことは、通常、最良の戦略です。
私が知っている別のサイトは、分散型アカウント管理に対してかなりエレガントなアプローチをとっています。それらには、通常のパッケージ管理手順と自動化インフラストラクチャを使用してシステムにインストールされるuser- *およびsudo- *パッケージ（RPMなど）があります。その場合、sudo- *パッケージは対応するuser- *パッケージに依存します。これは、ローカライズされたアカウント（すべてのアカウントは管理者、開発者、サポートスタッフ、または「ヘッドレス」アカウント）を備えたマシンのクラスターを持つことができ、LDAP / NISまたは他のネットワークIDおよび認証サービスへの依存を排除するので、すばらしいです。（これにより、システム間の結合が減少し、システムが大幅に堅牢になります）。
そのアプローチについて私が好きだと思うのは、柔軟性を与えることです。sudoアクセス権を持つユーザーは、コマンドを発行して、通常のユーザーまたは別のsudoユーザーアカウントを追加できます。そのため、私がチケットで作業している場合、すでにシステムへのアクセス権を持っている人なら誰でも簡単にアクセス権を取得できます。中央データベースのアクセス制御リストに私を追加するためのチケットが、中央集中型の承認プロセスを経て、最終的に問題のシステムに変更を反映するまでの遅延はありません。sudoシステムの許可されたユーザーのいずれかが私にアクセス権を与え、後で私を削除する可能性があります。（私が悪であり、彼らが私をゲームにかけたらsudo悪意を持って変更を加えてアクセスを保持することができます。実際、通常のユーザーと同じように、削除後もアクセスを保持するために実行できることがいくつかあります。しかし、それは彼らが心配している脅威ではありません。私のアクセスは、まだ全体的に比較的少数のシステムに制限されています。したがって、侵害されたアカウントの影響は、私が見たほとんどの同様のスキームよりもさらに制限されます。
リモートルートアクセスを無効にすると、リモートの攻撃者が直接ルートを取得できなくなります。攻撃者は別のアカウントを破壊し、マシンにアクセスしてから、ルートにアクセスしようとします。これは追加の手順です。
一般に、ルートはリモートアクセスに対して無効になっています。SUはうまく機能します。何かが本当に壊れた場合、それを修正するために常にボックスに直接アクセスできます。
より厳格になりたい場合は、ルートを完全に無効にしてください。sudoが目的です。繰り返しますが、そのアプローチでも、Ubuntuのシングルユーザーモードにドロップすることで、ルートアクセスを取得できます。しかし、彼らのドキュメントによると、彼らはそのためにパッチを当てたinitを使用したと思います。
さらに、端末が開いたままで、PCも開いている場合に、アイドル状態のユーザーをアイドル状態のユーザーを開始するように設定できます。すべてのユーザーにキーの使用を強制することはできますが、キーの管理は難しい場合があります。
ブレイクグラスタイプのシステムとしての単一のパススルーロギングホストも、追加の保護層と監査証跡を強制しました。
コンソールでのみrootアクセスを許可するようにシステムをセットアップすることをお勧めします。
それ以外の場合は、sudoとパスワードオプションを使用して、選択したユーザーに特権コマンドへのアクセスを許可します。ところで、sudoは、必要に応じてユーザーアカウントを特定のコマンドに制限するように設計できることに注意してください。須藤は、それが使用されたことをシステムログに「マーク」を残します rootパスワードは公開されないため、sudoはsuより優れています。したがって、rootパスワードを変更でき、sudoを使用するユーザーは賢くなりません。
sudoを使用してpriv'dコマンドにアクセスできるようにするには、環境に応じた頻度でパスワードを定期的に変更する必要があります。
ルートを許可しない
パスワードのみでなくキーでアクセスできるようにシステムを設定する
次に、rootアカウントを介して変更を行うことを許可されたユーザーにsudoを設定します