rootとして機能する複数のLinuxシステム管理者
私たちのチームでは、経験豊富な3人のLinuxシステム管理者が数十台のDebianサーバーを管理する必要があります。以前は、SSH公開鍵認証を使用してrootとして作業していました。しかし、そのシナリオのベストプラクティスとは何かについて話し合ったため、何も合意できませんでした。
みんなのSSH公開鍵は〜root/.ssh/authorized_keys2に置かれます
- 利点：使いやすく、SSHエージェント転送は簡単に機能し、オーバーヘッドはほとんどありません
- 短所：監査が欠落している（どの「ルート」が変更を行ったかがわからない）、事故の可能性が高い
パーソナライズされたアカウントとSudoの使用
そうすれば、SSH公開鍵を使用してパーソナライズされたアカウントでログインし、Sudoを使用してroot権限で単一のタスクを実行できます。さらに、ログファイルの表示を許可する「adm」グループを自分に与えることもできます。
- 利点：優れた監査Sudoばかげたことを簡単に行うことができなくなります
- 短所：SSHエージェントの転送が中断します。ほとんどの場合、非ルートとして実行できるため、面倒です
複数のUID 0ユーザーの使用
これは、システム管理者の1人からの非常にユニークな提案です。/etc/passwdに3人のユーザーを作成することをお勧めします。ユーザーはすべてUID 0ですが、ログイン名は異なります。これは実際には禁止されておらず、誰もがUID 0になることを許可するが、監査は可能であると彼は主張します。
- 利点：SSHエージェント転送が機能し、監査が機能する（テストされていない）可能性があるSudo面倒
- 欠点：かなり汚い感じ-許可された方法として文書化された場所が見つからなかった
何を提案しますか？
2番目のオプションは、私見の最良のものです。個人アカウント、Sudoアクセス。 SSH経由のルートアクセスを完全に無効にします。数百のサーバーと6ダースのシステム管理者がいますが、これが私たちのやり方です。
エージェント転送はどのように正確に中断しますか？
また、すべてのタスクの前でSudoを使用するような面倒な場合は、Sudo -sでSudoシェルを呼び出すか、Sudo su -でルートシェルに切り替えることができます。
@ jlliagreが推奨するuseradd -o -u userXXXオプションの閲覧以外に、3番目に推奨される戦略については、同じuidとして複数のユーザーを実行することに慣れていません。 （したがって、それを続行する場合は、発生した問題（または成功）で投稿を更新できるかどうか興味があります...）
私は最初のオプション「誰のSSH公開鍵も〜root/.ssh/authorized_keys2に入れられる」に関する最初の観察は、絶対に他のシステムで作業するつもりがない限りはそうだと思います。
- その後、少なくとも一部の場合、ユーザーアカウントと
Sudoを使用する必要があります
2番目の観察は、HIPAA、PCI-DSSコンプライアンス、またはCAPPやEALなどを志向するシステムで作業する場合、Sudoの問題を回避する必要があるということです。
- 業界標準ルート以外の個々のユーザーアカウントを提供します。これは、通常、いくつかの集中ユーザーデータベースを使用して、監査、無効化、期限切れなどを行うことができます。
そう; 個人用アカウントとSudoを使用
残念ながら、システム管理者として、リモートマシンで実行する必要のあるほとんどすべての操作には、いくつかの昇格されたアクセス許可が必要になりますが、SSHベースのツールとユーティリティのほとんどがSudo
したがって、あなたが言及しているSudoの煩わしさを回避するために使用するいくつかのトリックを渡すことができます。最初の問題は、PermitRootLogin=noを使用してrootログインがブロックされている場合、またはsshキーを使用してrootを持っていない場合、SCPファイルがPITAのようなものになることです。
問題1：リモート側からファイルをscpしたいが、ルートアクセスが必要ですが、リモートボックスに直接rootとしてログインすることはできません。
退屈なソリューション：ファイルをホームディレクトリにコピーし、chown、scpダウンします。
ssh userXXX@remotesystem、Sudo su -など、cp /etc/somefilesから/home/userXXX/somefiles、chown -R userXXX /home/userXXX/somefiles、scpを使用してリモートからファイルを取得します。
とても退屈です。
Less Boring Solution：sftpは-s sftp_serverフラグをサポートしているため、次のようなことができます（/etc/sudoersでパスワードなしのSudoを設定している場合）。
sftp -s '/usr/bin/Sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
（このハックアラウンドをsshfsで使用することもできますが、推奨されるかどうかはわかりません... ;-)
パスワードなしのSudo権限がない場合、または構成された理由で上記の方法が無効になっている場合は、リモートルートファイルにアクセスするために、退屈なファイル転送方法をもう1つ減らすことをお勧めします。
ポート転送忍者メソッド：
リモートホストにログインしますが、リモートポート3022（空いていても管理者用に予約されていないもの、つまり> 1024）をローカル側のポート22に転送するように指定します。
[localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
通常の方法でルートを取得...
-bash-3.2$ Sudo su -
[root@remotehost ~]#
これで、ファイルの中間コピーを作成するという退屈な退屈なステップを回避して、ファイルを逆方向にscpできます。
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
問題2：SSHエージェント転送：ルートプロファイルをロードした場合ログインシェルを指定すると、SSH_AUTH_SOCKなどのSSHエージェント転送に必要な環境変数がリセットされるため、SSHエージェント転送はSudo su -で「壊れ」ます。
半分焼きたての答え：
ルートシェルを適切にロードするものはすべて環境を正しくリセットしますが、ルート権限とSSHエージェントを使用する機能の両方が必要なときに使用できるわずかな回避策があります同時に
これは一種のキメラプロファイルを実現しますが、実際には使用しないでくださいこれは厄介なハックであるためですが、リモートホストからルートとして、他のリモートホストにSCPファイルをSCPする必要がある場合に役立ちます。 。
とにかく、sudoersで以下を設定することにより、ユーザーがENV変数を保持できるようにすることができます。
Defaults:userXXX !env_reset
これにより、そのような厄介なハイブリッドログイン環境を作成できます。
通常どおりログインします。
[localuser@localmachine ~]$ ssh userXXX@remotehost
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971
/root/.profileおよび/root/.bashrcを実行するbashシェルを作成します。ただし、SSH_AUTH_SOCKは保持します
-bash-3.2$ Sudo -E bash -l
したがって、このシェルにはroot権限とroot $PATHがあります（ただし、ホームディレクトリが壊れています...）。
bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin
しかし、その呼び出しを使用して、リモートのSudoルートだけでなく、SSHエージェントのアクセスも必要とすることを実行できます。
bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-Host:~
/root/.ssh/authorized_keys 100% 126 0.1KB/s 00:00
bash-3.2#
3番目のオプションは理想的に見えますが、実際に何が起こっているかを確認するために試しましたか？ mightが認証ステップで追加のユーザー名を表示している間、逆引き参照は同じ値を返します。
マシンがインターネットに接続されていない場合でも、強力なパスワードを使用している場合でも、ルートの直接sshアクセスを許可することはお勧めできません。
通常、ルートアクセスにはSudoではなく「su」を使用します。
（1）を使用していますが、たまたま入力しました
rm -rf/tmp *
ある悪い運命の日に。もしあなたが一握りの管理者以上を持っているなら、私は十分に悪いと見ることができます。
（2）おそらくもっとエンジニアリングされている-そしてあなたはSudo suを通じて本格的なrootになることができる-事故はまだ可能です。
（3）はしけ棒には触れない。私はそれをSunsで使用し、barebone-sh以外のrootアカウント（正しく覚えていれば）を得るために使用しましたが、決して堅牢ではありませんでした。
間違いなく答える2。
rootとしてSSHアクセスを許可していることを意味します。このマシンが一般に公開されている場合、これはひどい考えです。ポート22でSSHを実行したとき、私のVPSは毎時間、rootとして認証するために複数回の試行を受けました。複数の試行に失敗したIPをログに記録して禁止するように基本的なIDSを設定しましたが、それらは引き続き使用されました。ありがたいことに、自分のアカウントとSudoを構成したらすぐに、rootユーザーとしてのSSHアクセスを無効にしました。さらに、これを実行する監査証跡は事実上ありません。必要に応じてルートアクセスを提供します。はい、標準ユーザーとしての特権はほとんどありませんが、これはまさにあなたが望むものです。アカウントが危険にさらされた場合は、その機能を制限する必要があります。スーパーユーザーがアクセスするには、パスワードの再入力が必要です。さらに、Sudoアクセスはユーザーグループを介して制御でき、必要に応じて特定のコマンドに制限できるため、誰が何にアクセスできるかをより詳細に制御できます。さらに、Sudoとして実行されるコマンドをログに記録できるため、問題が発生した場合の監査証跡が大幅に改善されます。ああ、ログインしたらすぐに「Sudo su-」を実行しないでください。それはひどい、ひどい習慣です。
あなたのシステム管理者の考えは悪いです。そして彼は気分が悪いはずです。いいえ、* nixマシンではおそらくこれを止めることはできませんが、ファイルシステムとそこにあるほぼすべてのアプリケーションの両方が、各ユーザーが一意のUIDを持っていることを期待しています。この道を進み始めれば、問題が発生することは間違いありません。多分すぐにではなく、最終的には。たとえば、わかりやすい名前を表示しているにもかかわらず、ファイルとディレクトリはUID番号を使用して所有者を指定します。重複するUIDで問題が発生するプログラムに遭遇した場合、深刻な手動ファイルシステムクリーンアップを行わなくても、後でpasswdファイルのUIDを変更することはできません。
Sudoが前進です。 rootとしてコマンドを実行するとさらに面倒になる可能性がありますが、アクセスと監査の両方の点で、より安全なボックスが提供されます。
間違いなくオプション2ですが、グループを使用して、Sudoを使用する必要なく、各ユーザーにできるだけ多くの制御を与えます。すべてのコマンドの前にあるSudoは、常に危険ゾーンにいるため、メリットの半分を失います。 Sudoを使用せずに関連するディレクトリをsysadminsが書き込み可能にすると、Sudoが例外に戻され、誰もが安全に感じるようになります。
昔、須藤は存在しませんでした。その結果、複数のUID 0ユーザーを持つことが唯一の利用可能な代替手段となりました。しかし、特にユーザー名を取得するためにUIDに基づいてログを記録する場合は、まだそれほど良くありません。
現在、Sudoが唯一の適切なソリューションです。他のことは忘れてください。
それは事実上許容できる文書化されています。 BSD unicesは長い間toorアカウントを持っていました、そしてbashrootユーザーはcshが標準であるシステムで受け入れられた慣行である傾向があります（受け入れられた不正行為;）
変なことかもしれませんが、方法（3）も最初に思い浮かんだものです。長所：すべてのユーザーの名前がログに記録され、誰がrootとして何をしたかがわかります。短所：それぞれが常にルートであるため、間違いは破滅的となる可能性があります。
すべての管理者がrootアクセスを必要とする理由を質問したいと思います。提案する3つの方法すべてに1つの明確な欠点があります。管理者がSudo bash -lまたはSudo su -などの場合、誰が何をするかを追跡する能力を失い、その後、間違いは破滅的となる可能性があります。さらに、誤動作の可能性がある場合、これはさらに悪い結果になるかもしれません。
代わりに、別の方法を検討することをお勧めします。
- 通常のユーザーとして管理ユーザーを作成する
- 誰がどの仕事をする必要があるかを決める（Apache管理/ Postfix管理など）
- ユーザーを関連グループに追加します（「martin」を「postfix」と「mail」に追加する、「amavis」を使用する場合など）。
- 権限を修正（chmod -R g + w postfix：postfix/etc/postfix）
- sudoの相対的な能力のみを与える：（visudo-> martinに/etc/init.d/postfix、/ usr/bin/postsuperなどを使用させる）
このようにして、マーティンはpostfixを安全に処理できるようになり、ミスや誤動作が発生した場合、サーバー全体ではなく、postfixシステムのみが失われます。
同じロジックを、Apache、mysqlなどの他のサブシステムに適用できます。
もちろん、これは現時点では純粋に理論上のものであり、設定が難しい場合があります。それはあなたが行くためのより良い方法のように見えます。少なくとも私には。誰かがこれを試した場合は、それがどのように行われたか教えてください。