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

Question

在我们的团队中，我们有三位经验丰富的 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麻烦
• 缺点：感觉很脏 - 无法在任何地方找到它作为允许的方式记录

你有什么建议？

Answer 1

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

代理转发究竟是怎么断的？

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

Answer 2

关于第三个建议的策略，除了仔细阅读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您提到的烦恼的技巧。第一个问题是，如果PermitRootLogin=no使用 ssh 密钥阻止了 root 登录，或者您没有使用 ssh 密钥的 root，那么它会使 SCP 文件成为 PITA。

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

无聊的解决方案：将文件复制到主目录、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 中使用这个 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 ~]# 

现在您可以在另一个方向 scp 文件，避免制作文件的中间副本的无聊步骤；

[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 代理转发所需的环境变量（例如）将SSH_AUTH_SOCK被重置，因此 SSH 代理转发在sudo su -.

半成品答案：

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

这实现了一种不应该使用的嵌合配置文件，因为它是一个讨厌的 hack，但是当您需要以 root 身份将 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

创建一个 bash shell，它运行/root/.profile和/root/.bashrc. 但保留SSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

所以这个shell有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#