クラウドサーバーにパスワードなしの「Sudo」を設定してもよろしいですか？
キーを使用してサーバーにアクセスするというアイデアが気に入っています。ボックスにsshを入力するたびにパスワードを入力する必要がなく、ユーザーの（rootではなく）パスワードをロックすることさえできます（passwd -l username）したがって、キーなしでログインすることは不可能です。
しかし、Sudoコマンドにパスワードを入力する必要がある場合、これらすべてが機能しなくなります。だから私は passwordless Sudo を設定して、パスワードなしのログインと一致するようにします。
しかし、私はそれが予期しない方法で私に逆火を起こすかもしれないという直感を持ち続けています。このような設定での注意点はありますか？サーバー上のユーザーアカウントに対してこれを行うことをお勧めしますか、またはお勧めしませんか？
説明
- ここでは、インタラクティブなユーザーセッションでの
Sudoの使用について話しています。サービスや管理スクリプトではありません - クラウドサーバーの使用について話している（したがって、マシンへの物理的なローカルアクセスがなく、リモートでしかログインできない）
Sudoにはタイムアウトがあり、その間にパスワードを再入力する必要がないことを知っています。しかし、私のコンサートは、実際にパスワードを入力するために余分な時間を浪費することではありません。でも私の考えは、パスワードをまったく扱う必要がないということでした。- 覚える必要がある場合、短すぎて安全または再利用できない可能性が非常に高い
- リモートアカウント用に長くて一意のパスワードを生成した場合、どこかに保存し（ローカルパスワードマネージャープログラムまたはクラウドサービス）、
Sudoを使用するたびに取得する必要があります。私はそれを避けることができると思いました。
そのため、この質問では、1つの可能な構成と他の構成のリスク、警告、およびトレードオフをよりよく理解したいと思いました。
フォローアップ1
パスワードなしのSudoは、個人のユーザーアカウントが侵害された場合に特権を「簡単に」エスカレーションできるため、安全ではないとすべての回答が述べています。という事は承知しています。しかし、その一方で、パスワードを使用すると、パスワードに関する従来のリスクがすべて発生します（文字列が短すぎるか、一般的であり、異なるサービス間で繰り返されるなど）。しかし、/etc/ssh/sshd_configでパスワード認証を無効にして、ログインするためのキーがまだ必要な場合は、Sudoだけの簡単なパスワードを使用すると、入力が簡単になると思いますか？それは有効な戦略ですか？
フォローアップ2
Ssh経由でrootとしてログインするためのキーも持っている場合、誰かが私のコンピューターにアクセスして私のキーを盗むと（ただし、OSのキーリングパスワードでまだ保護されています！）、 rootパスをバイパスして、Sudoアカウントに直接アクセスします。では、rootアカウントにアクセスするためのポリシーはどうなっているのでしょうか。
キーを使用してサーバーにアクセスするというアイデアが好きなので、ボックスにSSHでログインするたびにパスワードを入力する必要はありません。ユーザーの（rootではなく）パスワード（passwd -l username）をロックするだけなので、キーなしでログイン...サーバーのユーザーアカウントに対してこれを行うことをお勧めしますか、またはお勧めしませんか？
あなたは間違った方法でパスワードベースのログインを無効にするつもりです。ユーザーのアカウントをロックする代わりに、PasswordAuthentication noあなたの/etc/ssh/sshd_config。
これを設定すると、sshのパスワード認証は無効になりますが、Sudoのパスワードは引き続き使用できます。
SudoでNOPASSWDを設定することをお勧めするonly時間は、プロセスがプログラムでSudoを介してコマンドを実行できる必要があるサービスアカウント用です。これらの状況では、アカウントが実行する必要がある特定のコマンドのみを明示的にホワイトリストに登録してください。インタラクティブなアカウントの場合、常にパスワードを有効にしておく必要があります。
フォローアップ質問への回答：
しかし、/ etc/ssh/sshd_configでパスワード認証を無効にして、ログインするためのキーがまだ必要な場合は、Sudoのためだけに入力しやすい、より単純なパスワードを使用できると思いますか？それは有効な戦略ですか？
それは正解です。比較的強力なローカルアカウントパスワードを使用することをお勧めしますが、とんでもないほど強力ではありません。ランダムに生成された最大8文字で十分です。
Ssh経由でrootとしてログインするための鍵も持っている場合、誰かが私のコンピューターにアクセスして私の鍵を盗むと（それらはまだOSのキーリングパスワードによって保護されています！）、それらに直接アクセスすることもできます。 rootアカウント。Sudoパスをバイパスします。
Ssh経由のルートアクセスは無効にする必要があります。限目。セットする PermitRootLogin noあなたのsshd_config。
では、rootアカウントにアクセスするためのポリシーは何でしょうか。
サーバーのコンソールへの帯域外アクセスを取得する手段が常に必要です。専用ハードウェアのベンダーと同様に、いくつかのVPSベンダーがこれを提供しています。プロバイダーが実際のコンソールアクセスを許可しない場合（たとえば、EC2など）、通常は、私が この答え で概説しているようなプロセスを使用してアクセスを復元できます。
私は通常、NOPASSWORDの使用を、自動化されたプロセスによって実行されるコマンドに制限しています。これらのコマンドにはサービスアカウントを用意し、Sudoの使用を必要なコマンドに制限することをお勧めします。
一般的なコマンドに対してNOPASSWORDを許可すると、ユーザーIDにアクセスできるすべてのユーザーが任意のコマンドを実行できるようになります。これは資格情報の侵害が原因で発生する可能性がありますが、1秒間離れたときに誰かが机に座っているのと同じくらい簡単な場合もあります。
頻繁にパスワードを入力する必要がないことがわかりました。パスワードを入力したら、それらの間であまり長く待たなければ、いくつかのコマンドを実行できます。タイムアウトは設定可能です。
ログインとSudoの両方にSSH認証を使用することで、両方の長所を持つことができます。 pam_ssh_agent_auth モジュールを統合すると、Sudo時にSSHキーを使用してパスワードを入力せずに認証できます。
私はこれを5年以上実稼働で使用しています。
これを構成するには、PAMモジュールをインストールしてから、/etc/pam.d/Sudoまたはシステムの同等の行に行を追加します。
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
これを行う場合は、必ずコンピューター上のキーをパスフレーズで保護してください。そうすれば、誰かがコンピュータに侵入して鍵を盗み、侵入する必要があります。アカウントにアクセスできる場合、ロックが解除されている間にメモリからそれらを引き出すか、パスフレーズをクラックするか、パスフレーズを盗むことでそれを行うことができます。入力中にキーロガーやショルダーサーフィンをする（後ろを見る！）.
ログイン時と同じSSHキーを使用することも、Sudo時にエージェントにのみ追加する別のキーを設定することもできます。したがって、さらに注意したい場合は、Sudoが必要な場合にのみエージェントに追加する個別のSSHキーを含む個別のauthorized_keysファイルを維持できます。
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_Sudo
これは次の2つの状況でのみ使用します。
- 絶対の場合特定のユーザーとして実行されている自動化スクリプトに必要
- 特定の管理タスク（システムを変更するためのアクションを実行するタスクではなく、読み取り専用の管理タスク）の場合はもちろん、特定のユーザーのみが対象
デフォルトでは、ほとんどのSudo構成は、同じセッションでしばらくの間再度尋ねることはありません（効果のない新しいシェルを開いた場合）。この動作は、timestamp_timeout設定である程度制御できます。
パスワードなしのSudoは、パスフレーズなしのsshキーほど危険ではありません。リモートの攻撃者はそもそも認証情報を取得する必要があるためですが、何らかの方法で侵入した場合、秘密鍵（または、それらが物理的にローカルであり、マシンから離れている間にログインしてロック解除したままにしている場合）の場合、パスワード要求は、それらと特権アクセスの間の貴重な追加防御になります。
フォローアップについて2：
Ssh経由でrootとしてログインするためのキーもある場合
あなたが説明する理由から、これも避けるのが一番です。リモート接続に特権アクセスが必要な場合は、サービスアカウントを介してログインし、Sudoを介してジョブを実行するのに十分な制御を与えます。これはもちろん設定するのがもっと面倒なので、多くは気にしない（攻撃者がそこに時間を費やすためにあなたよりも低いぶら下がっている果物がたくさんあるので、あなたがそうするならあなたに有利に働く）ので、それはセキュリティと利便性の間の古い妥協（プロのヒント：セキュリティを選択してください！）。
あなたが尋ねたので、Sudo問題に対処する方法に関する私の一般的なアドバイスを次に示します。
Sudoは、セキュリティを強化するようには設計されていません（ただし、ある程度の可能性はあります）...ではなく、システムで誰がどの特権をどのように実行しているかについての優れた監査証跡を提供します。
適切に設定されたSudoはALL=(ALL) ALL設定を使用しませんが、ユーザーが特に必要とするものに限定されます。たとえば、ユーザーがスタックしたサービスにログインして再起動できるようにする必要がある場合、おそらく新しいソフトウェアをインストールしたり、サーバーをシャットダウンしたり、ファイアウォールルールを変更したりする必要はありません。
人々がrootアカウントに昇格するためにSudoを使用することは時々一般的です。 Sudo su -。彼らがそれをしたら、あなたはrootアカウントからだれが何をしているのか見るのをやめます（rootは同時に複数回ログインすることができます）。したがって、Sudo su -コマンドも無効にしたい場合があります。ただし、実際的な理由から、管理に完全なroot特権のアカウントが必要な場合、少なくとも誰かがSudo su -コマンドを発行すると、誰がいつrootに昇格したかがログに記録されます。
ボックスを保護する方法：
SSHポートをデフォルト以外のポートに変更します。これは、ポート番号を探すダムボットが侵入するまでたどり着かないようにするためです（か否か）。
sshd_configのAllowRootLogin no設定を使用して、SSH経由でのルートログインを禁止します。これにより、誰かがルートアカウントにブルートフォースすることを防ぎます。監査上の理由とセキュリティ上の理由から、root/administratorアカウントに誰かが直接ログインすることを決して許可しないことは、一般的には良い習慣です。 rootログインを直接許可する場合、誰がログインしたか、誰がパスワードを入手したかなどはわかりません。しかし、誰かがJimmyのアカウントにログインし、その権限をrootに昇格した場合、どこから始めればよいかがわかります。監査検索（およびリセットするアカウント）。
ユーザーに必要なSSHのみを許可するAllowUsers設定を使用し、SSHアクセスが必要なアカウントを明示的に指定します。これにより、デフォルトで、他のすべてのアカウントがSSHからブロックされます。
visudoを介してSudoersを編集し、ユーザーが必要とするコマンドのみを許可します。これを行う方法に関する詳細なガイドがたくさんあるので、私はしません詳細はこちら。ここにスターターがあります： http://ubuntuforums.org/showthread.php?t=1132821
これの要点は、侵害されたアカウントがマシンを危険にさらすのを防ぐことです。すなわち。 Sallyのアカウントが侵入され、SallyがSudoを使用してのみWebサーバーを再起動できる場合、攻撃者はWebサーバーをループで再起動するのは楽しいかもしれませんが、少なくともrm -rf /your/webserver/directoryまたはすべてのファイアウォールを開くことはできませんポートなど.
適切なファイアウォールルールを設定して、ボックスの動作に必要なポートのみを許可します。通常はすべてを削除し、必要なものだけを明示的に許可します。まともなiptablesがたくさんあり、他のファイアウォールがオンラインで起動します。ここに私が使用するものがあります（これは基本的なスターターです）：
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
強力なパスワードもキーです。リモートアクセスにSSHキーを使用する場合でも、Sudoを使用するにはパスワードが必要です。これは、Sudoがセキュリティを強化できるケースです。誰かがあなたのsshキーを盗んだとしても、アカウントパスワードにブルートフォースを使用してSudoを使用しなければならない場合でも、ボックスで重要なことを行うことはできません。パスワードは単語ではなく、パスフレーズにする必要があります。文を考えて、それを使ってください。これは通常、8文字を超える長さになるため、十分なエントロピーを提供しますが、ランダムなパスワードよりも覚えやすくなります。もちろん、優れたパスワードプラクティスでは、John the Ripperのようなクラッキングツールをだますために、機械で生成されたランダムなパスワードを使用すると言っています。いいえ、Eを3に変更しても機能しません。ジョンもこれらの順列を取得します。
場合によっては、これを行う必要があります。例えば一部のハイパーバイザーAPIには、パスワードなしのログインとパスワードなしのSudoが必要です。しかし、それを壊すことなくそれを制限することができます。
あなたが達成しようとしていることのために。パスワードの入力に慣れるでしょう。ここでのセキュリティはセキュリティよりも便利です。さらに、本当にrootアクセスが必要な場合はSudoを使用できます。しばらくの間資格情報がキャッシュされるため、複数のSudoコマンドを続けて実行した場合、初回のみパスワードの入力を求められます。ですから、ご想像のとおり、それほど大きな不便はありません。
また、多くのroot特権コマンドを入力していて、常にSudoをそれらの前に置きたくない場合は、suまたはSudo -sルートシェルを取得します。パスワードを一度入力すると、それだけです。
パスワードなしのSudoに一度噛まれたことがある。それはシェルスクリプトで、インストーラーは私の代わりにSudoと呼ばれますですが、Sudoを要求したりエラーを出したりするだけです。
基本パスを設定または表示せずに、「make」と「Sudo make install」の部分を実行するスクリプトを入力するイメージング、および最初の場所でスクリプトが非常に死んでいるため、/ usr/localについて知っているかどうかは不明ですそして/ usrの変更をチェックし始めます...
私はNOPASSWDを再び使用しないことを誓い、そのタイムアウト設定を0に変更しました。
ここでの他の答えは素晴らしいです、そして重要なポイントのほとんどに触れます。私が言及していないことの1つは、自分でログインするときに行うあらゆる種類の認証が、すでにアカウントに足場を築いているリモートの攻撃者によってキャプチャされる可能性があるという事実です。シェルのログインファイルまたはPATHを変更してキーロガーをインストールし、Sudoパスワードを含むすべての入力内容が送信されるようにすることができます。ハッキングされたSudoバイナリをPATHに追加して、パスワードを収集する可能性があります。 sshエージェント接続を接続マシンにハイジャックしてpam_ssh_agent_authを無効にし、接続するとすぐにrootになります。したがって、絶対的なセキュリティの観点から、Sudoのパスワードを使用する場合と使用しない場合の違いはわかりません。もちろん、これはより複雑な攻撃になり、Sudoをすぐに使用したのではなく、一度使用した場合にのみrootになります。
要約すると、Sudoアクセスがある場合に、侵害されたユーザーアカウントがrootになるのを完全に防ぐ唯一の方法は、自分からSudoアクセスを削除するか、絶対に使用しないことです。あなたが同意しない場合は、私に知らせてください。
質問に厳密に回答するわけではありませんが、もう1つのオプションとして、より長いtimestamp_timeoutなので、頻繁にパスワードを入力する必要はありません。これにより、誰もが管理者特権を取得するのを防ぎ、煩わしさを軽減できます。
sudoers man page から：
timestamp_timeout
Sudoが再度パスワードを要求するまでの経過時間（分）。タイムアウトには、2.5など、細かい単位では不十分な場合、小数のコンポーネントが含まれることがあります。デフォルトは5です。これを0に設定すると、常にパスワードの入力を求められます。 0未満の値に設定すると、ユーザーのタイムスタンプが期限切れになることはありません。これを使用すると、ユーザーはそれぞれ「Sudo -v」および「Sudo -k」を介して独自のタイムスタンプを作成または削除できます。
このブログ投稿はいくつかの例を示していますvisudoを使用してタイムアウトを分単位で設定します。
Defaults timestamp_timeout=60
たぶん、これはセキュリティと使いやすさの間の幸せな中間点ですか？