SSHキー認証、それでもsudoのパスワードが必要ですか？
ほとんどのLinuxディストリビューションでは、公開秘密鍵認証を使用したSSHがデフォルトで有効になっています。リモートユーザーのアカウントを作成するときに、機密情報（パスワード）をメールで送信する必要がないため、これは素晴らしいことです。
ただし、これらのユーザーがSudoを実行する必要がある場合、このプロセスは役に立たなくなります。サーバーは引き続きパスワードを要求します。つまり、これらのユーザーのパスワードを生成し、安全に取得する方法を見つける必要があります。
sudoersファイルとNOPASSWORDパラメータについて知っています。しかし、それを有効にするのは不安です。ユーザーがSudoコマンドを実行する前に、なんらかの認証が必要です。
このトピックについていくつかの調査を行っているときに、 pam_ssh_agent_auth プロジェクトが見つかりました。私の理解から、ssh接続に使用されているのと同じ秘密鍵/公開鍵認証がSudoコマンドに使用できます。
このモジュールを配置すると、完全にパスワードなしのアカウントを作成できるようです。
このモジュールまたは同様のプロセスが標準のLinuxディストリビューション構成に含まれていないのはなぜですか？これがより広く採用されない理由は、私が見逃しているいくつかのセキュリティ警告がありますか？ passworded Sudoがpublic/private key Sudoよりも安全であると考えられるのはなぜですか？
パスワードの作成と管理を必要としない別のアプローチを試しています。ユーザーの公開キーを使用してキーベースの認証を設定し、sshのパスワードベースの認証を無効にし、空で期限切れのパスワード（passwd -de）。これにより、ユーザーは最初のログイン時にプロンプトが表示され、自分のパスワードを選択できます。
空のパスワードについて少し不安を感じていますが、私が知る限り、sshのパスワード認証が無効になっていて、認証を必要とする他のサービス（IMAPなど）が実行されていない限り問題ありません。これについての意見は？
システムにSudoをインストールすることも避けることをお勧めします。これは追加の攻撃経路であり、通常はそれを正当化するものではありません。このトピックについて詳しく知りたい場合は、Sudoの（誤）使用法に関する記事を書きました。 http://dmitry.khlebnikov.net/2015/07/should-we-use-Sudo-for- day-to-day.html
Re：元の質問-特権のないユーザーが特権コマンドを実行する必要がある場合は、次のトリックを使用できます。
- パスフレーズなしのSSHキーを生成する
- パブリック部分の前に次を追加します：
from="127.0.0.1",command="your_desired_command_here",no-pty,no-port-forwarding,no-agent-forwarding（SSHセッションをさらに制限することもできます。「man sshd」を参照してください）。キーはこのヘッダーからスペース文字で区切る必要があることに注意してください。 - その公開鍵を特権アカウントの〜/ .ssh/authorized_keysにインストールします
- ユーザーに秘密鍵を提供します（または、秘密鍵を使用して、ループバックインターフェイスを介して特権アカウントにSSHで単純に接続するスクリプトを作成します）
たとえば、特権アカウントがr_service（useradd -om -u0 -g0 -d /root/service -s /bin/bash r_serviceで作成）の場合、非特権アカウントからのその特権コマンドの呼び出しは次のようになります。
$ ssh -i ~/.ssh/privileged_command r_service@0
これにより、セキュリティモデルを損なうことなく、その特権コマンドを実行することをユーザーに許可します。
私の意見では、サーバー管理者向けのSudoは少しやりすぎです。ユーザーがログインし、ルートに（何らかのメカニズムを介して）アクセスできる場合、通常は保守タスクを実行し、90％以上の時間にわたってSudoを使用します。 Sudoの目的は、信頼されていないアプリケーションと管理者のようなタスクとの間の何らかの分離でログインしているアカウントを提供し、システムを変更していることをユーザーに通知することです（注意が必要です）。デスクトップの場合、両方が適用されます。ただし、サーバーの場合、ほとんどのタスクはすでにSudoを必要とするため、両方の点が弱くなります。 Sudoはきめ細かい制御でいくつかの利点がありますが、そのロギング機能に依存するには、リモートロギングを設定する必要があります。そうしないと、ルートアクセス権を持つユーザーが過去のログを改ざんする可能性があります。
これがより広く採用されない理由は、私が見逃しているいくつかのセキュリティ警告がありますか？
pam_ssh_agent_authは、sshで動作するためにssh-agent転送を必要とします。ただし、ユーザーのアカウントで実行されているすべての（cgroupされていない）プロセスがエージェントを使用してrootとしてコマンドを実行できるため、それを使用するのは少し無意味です。これにより、このようなすべてのプロセスがSudoを実行できるようになります。これは、NOPASSWORDパラメータが正確に行うことです。
私のアドバイスは、NOPASSWORDを持っていて、それに満足することです。それでも人々は「今はシステムを変更した」と感じますが、煩わしいパスワードはありません。
それでもパスワードが必要な場合は、平文で電子メールで送信できますが、初めて使用するときにパスワードを変更する必要があります。攻撃者が成功するには、電子メールとユーザーの秘密鍵の両方が必要です。彼らがすでに秘密鍵にアクセスできる場合、彼らは.bashrcそして、ユーザーが次回Sudoを取得したときに、攻撃者が知る必要のないパスワードを取得します。
SSH認証とセキュリティ特権は2つの異なるものであるため、デフォルトの機能として使用しても意味がありません。しかし、それは攻撃のためにもう1つのベクトルを開きます（ [〜＃〜] cve [〜＃〜] があります）、私の観点から、ユーザーがそれを使いすぎやすくするので、これは悪いことです。
パスワードについては、有効期間が短いパスワードをユーザーに送信し、最初のログイン後にパスワードの変更を要求する方法があります。または、アカウントを「登録」して、ハッシュのみを処理することを許可します。すべてのアプローチには長所と短所がありますが、インスピレーションを得るための良い場所は、商用および無料のシェルアカウントサービスです。