多个Linux系统管理员以root身份工作

在我们的团队中，我们有3名经验丰富的Linux系统管理员必须管理几十个Debian服务器。以前，我们所有人都使用SSH公钥身份验证作为root用户。但是我们讨论了在哪种情况下的最佳实践，对此没有达成共识。

每个人的SSH公钥都放在〜root / .ssh / authorized_keys2中

• 优势：易于使用，SSH代理转发轻松进行，开销很小
• 缺点：缺少审核（您永远不知道哪个“根”进行了更改），发生事故的可能性更大

使用个性化帐户和sudo

这样，我们将使用SSH公钥使用个性化帐户登录，并使用sudo以root权限执行单个任务。另外，我们可以给自己一个“ adm”组，使我们可以查看日志文件。

• 优点：良好的审核功能，sudo可以防止我们过于轻易地进行愚蠢的事情
• 缺点：SSH代理转发中断，这很麻烦，因为几乎所有操作都不能以非root用户身份完成

使用多个UID 0用户

这是来自一名系统管理员的非常独特的建议。他建议在/ etc / passwd中创建三个用户，每个用户的UID为0，但登录名不同。他声称这实际上并没有被禁止，并且允许每个人的UID为0，但仍然能够进行审核。

• 优点：SSH代理转发有效，审核可能有效（未试用），没有sudo麻烦
• 劣势：感觉很脏-找不到允许在任何地方记录的文件

你有什么建议？

第二种选择是最好的恕我直言。个人帐户，sudo访问。完全禁用通过SSH的root访问。我们有几百台服务器和六个系统管理员，这就是我们的工作方式。

代理转发如何完全中断？

另外，如果sudo在每个任务之前都遇到麻烦，则可以使用调用sudo shell sudo -s或使用切换到root shellsudo su -

关于第三个建议策略，除了仔细阅读useradd -o -u userXXX@jlliagre推荐的选项外，我不熟悉将多个用户作为同一个uid运行。（因此，如果您继续这样做，那么如果您可以将出现的任何问题（或成功情况）更新为最新消息，我将不感兴趣。）

我想我对第一个选项“每个人的SSH公钥都放入〜root / .ssh / authorized_keys2”的第一个观察结果是，除非您绝对不会在任何其他系统上工作，否则，请参见。

1. 然后至少在某些时候，您将不得不使用用户帐户并sudo

第二个观察结果是，如果您在渴望实现HIPAA，PCI-DSS兼容或CAPP和EAL之类的系统上工作，那么您将不得不解决sudo问题。

2. 提供非root用户个人帐户的行业标准，该帐户通常可以使用某些集中式用户数据库进行审核，禁用，过期等。

所以; 使用个性化帐户和sudo

不幸的是，作为系统管理员，几乎需要在远程计算机上执行的所有操作都需要某些提升的权限，但是令人讨厌的是，大多数基于SSH的工具和实用程序在您进入时都被破坏了。 sudo

因此，我可以传递一些我用来解决sudo您提到的烦恼的技巧。第一个问题是，如果使用阻止了root登录，PermitRootLogin=no或者如果您没有使用ssh key进行root登录，那么它将使SCP文件有点像PITA。

问题1：您想从远程端对文件进行scp，但是它们需要root访问权限，但是您不能直接以root用户身份登录到远程文件夹。

无聊的解决方案：将文件复制到主目录，chown和scp下。

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中使用这种hack-around，但是我不确定它是否建议使用... ;-)

如果您没有无密码的sudo权限，或者出于某种配置原因，上述方法被破坏，我可以建议使用一种更无聊的文件传输方法来访问远程根文件。

忍者港前进法：

登录到远程主机，但指定要将远程端口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 ~]# 

现在，您可以从另一个方向对文件进行压缩，从而避免了制作文件中间副本的无聊步骤。

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

问题2：SSH代理转发：如果通过例如指定登录shell加载根配置文件，SSH_AUTH_SOCK则会重置SSH代理转发所必需的环境变量，例如，因此SSH代理转发在“下” sudo su -。

半生不死的答案：

凡是正确地加载一个root shell，将会理所当然重置环境，但有轻微的工作-在你可以用，当你既需要root权限，并使用SSH代理的能力，在同一时间

这实现了一种实际上不应该使用的嵌合体配置文件，因为它是一个令人讨厌的hack，但是当您需要将远程主机的SCP文件作为root用户传输到其他远程主机时，此配置很有用。

无论如何，通过在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

创建的bash shell下，运行/root/.profile和/root/.bashrc。但保留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 root和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# 

第三个选项看起来很理想-但是您是否实际尝试过看看是否发生了什么？虽然您可能会在身份验证步骤中看到其他用户名，但任何反向查找都将返回相同的值。

即使您的计算机未连接到Internet /使用强密码，也不允许root直接ssh访问。

通常我使用'su'而不是sudo进行根访问。

我使用（1），但我碰巧输入

rm -rf / tmp *

如果您的管理员人数不多，我会感到非常糟糕。

（2）可能是经过更多工程设计的，您可以通过sudo su成为完整的root。事故仍然有可能发生。

（3）我不会碰驳船竿。我在Suns上使用了它，以便拥有一个非准系统的root帐户（如果我没记错的话），但是它从来都不可靠-再加上我怀疑它是否可以审核。

绝对答案2。

1. 表示您允许SSH访问为root。如果这台机器以任何方式面向公众，那都是一个糟糕的主意。回到当我在端口22上运行SSH时，我的VPS每小时进行多次尝试以root用户身份进行身份验证。我建立了一个基本的IDS来记录和禁止IP，这些IP多次尝试失败，但是一直持续。幸运的是，一旦我拥有自己的帐户并配置了sudo，便以root用户身份禁用了SSH访问。此外，您几乎没有审核记录。

2. 在需要时提供根访问权限。是的，您作为标准用户几乎没有任何特权，但这几乎正是您想要的；如果帐户确实遭到入侵，则您希望限制其功能。您希望任何超级用户访问权限都要求重新输入密码。此外，可以通过用户组控制sudo访问，并且可以根据需要将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 unice的职责由来已久，并且bashroot用户倾向于在以csh为标准的系统上接受惯例（可接受的不当行为；）

也许我很奇怪，但是方法（3）也是我首先想到的。优点：您会在日志中拥有每个用户的名称，并且会知道谁以root身份进行了操作。缺点：他们每个人都一直都是根，所以错误可能是灾难性的。

我想问一个问题，为什么您需要所有管理员才能具有root用户访问权限。您提出的所有3种方法都有一个明显的缺点：管理员运行一个sudo bash -l或sudo su -多个这样的方法后，您将失去跟踪谁进行操作的能力，此后，错误可能是灾难性的。此外，在可能出现的错误行为的情况下，这甚至可能变得更糟。

相反，您可能需要考虑采用另一种方法：

• 将您的管理员用户创建为普通用户
• 确定谁需要做哪些工作（apache管理/ postfix管理等）
• 将用户添加到相关组（例如，将“马丁”添加到“后缀”和“邮件”，“ amavis”（如果使用的话，等等））
• 修复权限（chmod -R g + w postfix：postfix / etc / postfix）
• 只给出相对的sudo权限：（visudo->让Martin使用/etc/init.d/postfix，/ usr / bin / postsuper等）

这样，马丁将能够安全地处理后缀，并且在出现错误或行为不当的情况下，您只会丢失后缀系统，而不会丢失整个服务器。

相同的逻辑可以应用于任何其他子系统，例如apache，mysql等。

当然，这在目前是纯理论上的，可能很难设置。看起来确实是更好的选择。至少对我来说。如果有人尝试过，请让我知道如何进行。