ルートとして機能する複数のLinuxシステム管理者

私たちのチームでは、数十人のDebianサーバーを管理しなければならない3人の経験豊富なLinuxシステム管理者がいます。以前は、SSH公開キー認証を使用して、すべてrootとして作業していました。しかし、私たちはそのシナリオのベストプラクティスについて議論しましたが、何にも同意できませんでした。

全員のSSH公開キーは〜root / .ssh / authorized_keys2に配置されます

• 利点：使いやすく、SSHエージェント転送が簡単に機能し、オーバーヘッドが少ない
• 短所：監査が欠落している（どの「ルート」が変更を行ったかがわからない）

パーソナライズされたアカウントとsudoを使用する

この方法では、SSH公開キーを使用してパーソナライズされたアカウントでログインし、sudoを使用してルート権限で単一のタスクを実行します。さらに、ログファイルを表示できる "adm"グループを提供することもできます。

• 利点：優れた監査、sudoにより、ばかげたことを簡単に行えない
• 欠点：SSHエージェントの転送が中断します。ルート以外でほとんど何もできないため、面倒です。

複数のUID 0ユーザーを使用する

これは、システム管理者の一人からの非常にユニークな提案です。彼は/ etc / passwdに3人のユーザーを作成し、それらはすべてUID 0であるがログイン名が異なることを提案しています。彼は、これは実際には禁止されておらず、すべてのユーザーがUID 0であっても監査できることを許可していると主張しています。

• 利点：SSHエージェント転送の作品、監査かもしれない作業（未テスト）、なしのsudo面倒
• 欠点：かなり汚い-許可された方法としてどこにも文書化されていない

何を提案しますか？

2番目のオプションは、最高のオプションです。個人アカウント、sudoアクセス。SSH経由のルートアクセスを完全に無効にします。数百台のサーバーと6ダースのシステム管理者がいます。これが私たちのやり方です。

エージェント転送はどのように正確に中断しますか？

また、sudoすべてのタスクの前でこのような手間がかかる場合は、sudoシェルを呼び出すsudo -sか、ルートシェルに切り替えることができます。sudo su -

useradd -o -u userXXX@jlliagreが推奨するオプションの閲覧以外の3番目の提案された戦略に関しては、同じuidとして複数のユーザーを実行することには慣れていません。（したがって、あなたがそれを進めるなら、私はあなたが発生する問題（または成功）で投稿を更新できるかどうかに興味があります...）

最初のオプション「Everybody's SSH public key are put to〜root / .ssh / authorized_keys2」に関する私の最初の観察は、絶対に他のシステムで作業することはないということです。

1. その後、少なくともいくつかの時間、あなたはユーザーアカウントで作業する必要がありますsudo

2番目の観察結果は、HIPAA、PCI-DSS準拠、またはCAPPやEALなどを目指すシステムで作業している場合、sudoの問題を回避する必要があるということです。

2. 通常、一部の集中ユーザーデータベースを使用して、監査、無効化、有効期限切れなどが可能な非ルートの個別ユーザーアカウントを提供することが業界標準です。

そう; パーソナライズされたアカウントとsudoを使用する

システム管理者として、リモートマシンで行う必要のあるほぼすべての操作に何らかの昇格されたアクセス許可が必要になるのは残念ですが、SSHベースのツールとユーティリティのほとんどが使用中に破壊されるのは面倒です sudo

したがって、私はsudoあなたが言及することの迷惑を回避するために使用するいくつかのトリックを渡すことができます。最初の問題は、rootログインがPermitRootLogin=nosshキーを使用してブロックされているか、rootがsshキーを使用していない場合、SCPファイルがPITAのようなものになることです。

問題1：リモート側からファイルをscpしたいが、ルートアクセスが必要ですが、ルートとして直接リモートボックスにログインすることはできません。

退屈な解決策：ファイルをホームディレクトリにコピーし、chown、scp downします。

ssh userXXX@remotesystem、sudo su -など、cp /etc/somefilesに/home/userXXX/somefiles、chown -R userXXX /home/userXXX/somefilesリモートからファイルを取得するために使用SCP、。

本当に退屈です。

退屈さの少ないソリューション：sftpは-s sftp_serverフラグをサポートしているため、次のようなことができます（パスワードなしのsudoをで構成した場合 /etc/sudoers）。

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エージェント転送に必要な環境変数などSSH_AUTH_SOCKがリセットされるため、SSHエージェント転送はで「破損」しsudo su -ます。

半分焼いた答え：

適切には、rootシェルをロードすることを何でも、当然環境をリセットしようとしている、しかし、わずかな作業は、周りがあり、あなたの缶を使用しますが、BOTH root権限とSSHエージェントを使用する能力を必要とするとき、同時に

これはある種のキメラプロファイルを実現します。これは実際には使用すべきではありません。これは厄介なハックなので、リモートホストから他のリモートホストへファイルを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およびを実行するbashシェルを作成します/root/.bashrc。しかし、保存しますSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

したがって、このシェルにはルート権限があり、ルート$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番目のオプションは理想的なように見えますが、実際に何が起こっているのか試してみましたか？認証手順で追加のユーザー名が表示される場合がありますが、逆引きを行うと同じ値が返されます。

マシンがインターネットに接続されていない場合や強力なパスワードを使用している場合でも、rootの直接sshアクセスを許可することはお勧めできません。

通常、ルートアクセスにはsudoではなく「su」を使用します。

（1）を使用していますが、たまたま入力しました

rm -rf / tmp *

運が悪い1日。一握り以上の管理者がいる場合、十分に悪いことがわかります。

（2）おそらくもっと設計されています-そして、sudo suで本格的なルートになります- しかし、事故はまだ可能です。

（3）バージポールには触れません。ベアボーンsh以外のルートアカウント（正しく覚えている場合）を取得するためにSunsで使用しましたが、決して堅牢ではありませんでした-さらに、非常に監査可能であるとは思いません。

間違いなく答えてください2。

1. としてSSHアクセスを許可していることを意味しますroot。このマシンが何らかの方法で公開されている場合、これはひどい考えです。ポート22でSSHを実行すると、VPSはルートとして認証するために1時間ごとに複数回試行されました。IPをログに記録して禁止するための基本的なIDSをセットアップしましたが、複数の試行が失敗しましたが、それらは継続して行われました。ありがたいことに、自分のアカウントとsudoを設定したらすぐに、rootユーザーとしてSSHアクセスを無効にしました。さらに、これを行う監査証跡は事実上ありません。

2. 必要なときにルートアクセスを提供します。はい、標準ユーザーとしての特権はほとんどありませんが、これはまさにあなたが望むものです。アカウントが侵害された場合、その機能を制限する必要があります。スーパーユーザーアクセスには、パスワードの再入力が必要です。さらに、sudoアクセスはユーザーグループを通じて制御でき、必要に応じて特定のコマンドに制限できるため、誰が何にアクセスできるかをより詳細に制御できます。さらに、sudoとして実行されるコマンドをログに記録できるため、問題が発生した場合の監査証跡が大幅に向上します。ああ、ログインしてすぐに「sudo su-」を実行しないでください。それはひどい、ひどい習慣です。

3. あなたのシステム管理者の考えは悪いです。そして彼は気分が悪いはずです。いいえ、* nixマシンはおそらくこれを行うことを止めることはありませんが、ファイルシステムとそこにある事実上すべてのアプリケーションの両方が、各ユーザーが一意のUIDを持っていることを期待しています。あなたがこの道を歩き始めたら、私はあなたが問題にぶつかることを保証できます。すぐにではなく、最終的には。たとえば、わかりやすい名前を表示しているにもかかわらず、ファイルとディレクトリはUID番号を使用して所有者を指定します。重複したUIDに問題があるプログラムに遭遇した場合、後で深刻な手動ファイルシステムクリーンアップを行わずに、passwdファイルのUIDを変更することはできません。

sudo今後の道です。rootとしてコマンドを実行すると、さらに面倒になりますが、アクセスと監査の両方の面で、より安全なボックスを提供します。

間違いなくオプション2ですが、グループを使用して、sudoを使用せずに各ユーザーにできるだけ多くの制御を与えます。すべてのコマンドの前にあるsudoは、常に危険ゾーンにいるため、利益の半分を失います。関連するディレクトリをsudoなしでsysadminsによって書き込み可能にすると、sudoが例外に戻り、誰もが安全に感じるようになります。

昔は、sudoは存在しませんでした。結果として、複数のUID 0ユーザーを持つことが唯一の利用可能な代替手段でした。ただし、特にユーザー名を取得するためにUIDに基づいてログを記録する場合は、それほど良くありません。

現在、sudoが唯一の適切なソリューションです。他のものは忘れてください。

事実上、文書化されています。BSDユニックスは長い間彼らのtoorアカウントを持っていて、bashrootユーザーはcshが標準であるシステムで受け入れられている慣習である傾向があります（受け入れられた不正行為;）

おそらく私は奇妙ですが、方法（3）も最初に頭に浮かんだものです。長所：すべてのユーザーの名前をログに記録し、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などを使用させます）

この方法で、マーティンは後置を安全に処理でき、間違いや誤動作が発生した場合、サーバー全体ではなく、後置システムのみを失うことになります。

同じロジックを、Apache、mysqlなどの他のサブシステムに適用できます。

もちろん、これはこの時点では純粋に理論的なものであり、設定するのは難しいかもしれません。それはカントーに行くより良い方法のように見えます。少なくとも私には。誰かがこれを試してみたら、それがどうなったか教えてください。