在我们的团队中，我们有三位经验丰富的Linux系统pipe理员不得不pipe理几十个Debian服务器。 以前我们都使用SSH公钥authentication作为root工作。 但是我们讨论了这种情况下的最佳做法，而且什么都不能达成一致。
这样我们就可以使用SSH公共密钥login个性化帐户，并使用sudo以root身份执行单个任务。 另外我们可以给自己一个“adm”组，让我们查看日志文件。
这是来自系统pipe理员的一个非常独特的build议。 他build议在/ etc / passwd中创build三个UID为0但login名不同的用户。 他声称这实际上并没有被禁止，并且允许每个人都可以使用UID，但仍然可以进行审计。
你会build议什么？
第二个选项是最好的一个恕我直言。 个人账户，sudo访问。 完全禁用通过SSH的根访问。 我们有几百个服务器和六个系统pipe理员，这是我们如何做到的。
代理转发如何中断？
另外，如果在每个任务前面使用sudo都很麻烦，可以使用sudo -s调用sudo shell，或者使用sudo su -切换到root shell，
关于第三个build议的策略，除了阅读useradd -o -u userXXX推荐的useradd -o -u userXXX选项之外，我不熟悉将多个用户作为同一个uid运行。 （因此，如果你继续这样做，我会感兴趣，如果你可以更新post与任何问题（或success）出现…）
我想我的第一个观点是关于第一个选项“每个人的SSH公钥被放入〜root / .ssh / authorized_keys2”，这是因为除非你绝对不会在任何其他系统上工作。
sudo 第二种观察是，如果你的系统是渴望HIPAA，PCI-DSS合规性或CAPP和EAL之类的东西，那么你将不得不解决sudo的问题，因为;
所以; 使用个性化帐户和sudo
不幸的是，作为一个系统pipe理员，几乎所有你需要在远程计算机上执行的操作都需要一些提升的权限，然而令人讨厌的是，当你在sudo时候，大多数基于SSH的工具和工具都被中断
因此，我可以传递一些技巧来处理你提到的sudo的烦恼。 第一个问题是，如果使用PermitRootLogin=no阻止rootlogin，或者您没有使用ssh密钥的root，那么它会让SCPlogging一些PITA。
问题1 ：您想从远程端scp文件，但它们需要root权限，但是不能以root身份直接login到远程框。
镗解决scheme ：将文件复制到主目录，chown和scp下。
ssh userXXX@remotesystem ， sudo su - etc， cp /etc/somefiles到/home/userXXX/somefiles ， chown -R userXXX /home/userXXX/somefiles ，使用scp从远程检索文件。
非常无聊的确。
减less烦人的解决scheme ：sftp支持-s sftp_server标志，因此您可以执行如下操作（如果您在/etc/sudoersconfiguration了无密码sudo）;
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \ userXXX@remotehost:/etc/resolv.conf
（你也可以使用sshfs这个黑客技术，但我不确定它的build议… 😉
如果您没有无密码的sudo权限，或者由于某些configuration的原因，上述方法被破坏，我可以build议一个更无聊的文件传输方法，以访问远程根文件。
港口前锋忍者方法 ：
login到远程主机，但是指定远程端口3022（可以是任何东西都是空闲的，并且对于pipe理员来说是非保留的，即> 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代理转发 ：如果加载根configuration文件，例如通过指定loginshell，SSH代理转发的必要环境variables（如SSH_AUTH_SOCK被重置，因此sudo su -下的SSH代理转发将“中断”。
半熟的答案 ：
任何正确加载root shell的东西都会正确地重置环境，但是当你需要root权限和在同一时间使用SSH代理的能力时，你可以使用一些轻微的工作
这实现了一种chimeraconfiguration文件，实际上不应该使用， 因为它是一个讨厌的黑客 ，但是当你需要将SCP文件从远程主机作为root用户到其他远程主机时，它是有用的。
无论如何，您可以通过在sudoers中设置以下内容来启用您的用户可以保留其ENVvariables的function;
Defaults:userXXX !env_reset
这可以让你创build令人讨厌的混合login环境，就像这样;
正常login;
[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
创build一个bash shell，运行/root/.profile和/root/.bashrc 。 但保留了SSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
所以这个shell有root权限，root $PATH （但是一个borked home目录…）
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#
第三个选项看起来是理想的 – 但你真的试过看看发生了什么？ 虽然您可能在身份validation步骤中看到其他用户名，但任何反向查找都将返回相同的值。
即使您的机器没有连接到互联网/使用强密码，允许root用户直接访问ssh也不是一个好主意。
通常我使用“su”而不是sudo来进行root访问。
我使用（1），但我碰巧打字
rm -rf / tmp *
在一个不幸的一天。如果你有一些pipe理员，我可以看到已经够糟糕了。
（2）可能更多devise – 你可以通过sudo su来成为完整的根。 事故仍然有可能。
（3）我不会碰驳驳船杆。 我在太阳使用它，为了有一个非准系统帐户（如果我没有记错的话），但它从来没有健壮的 – 加上我怀疑这将是非常可审计的。
绝对回答2。
意味着您允许以root身份进行SSH访问。 如果这台机器以任何方式面向公众，这只是一个可怕的想法; 当我在端口22上运行SSH时，我的VPS每小时都有多次尝试以root身份进行身份validation。 我设置了一个基本的IDS来logging和禁止多次尝试失败的IP，但是他们一直在进来。 值得庆幸的是，只要我有我自己的帐户和sudoconfiguration，我已经作为root用户禁用SSH访问。 此外，您几乎没有审计线索这样做。
在需要时提供root访问权限。 是的，你几乎没有任何标准用户的权限，但这几乎是你想要的; 如果一个帐户被盗用，你希望它的能力受到限制。 您希望任何超级用户访问权限都需要重新input密码。 此外，sudo访问可以通过用户组进行控制，并且只要您喜欢，就可以限制到特定的命令，让您更好地控制谁可以访问哪些内容。 另外，以sudo方式运行的命令可以被logging下来，所以如果出现问题，它提供了一个更好的审计logging。 噢，login后，不要只是运行“sudo su – ”。这是可怕的，可怕的做法。
你系统pipe理员的想法很糟糕。 而且他应该感觉不好。 不，nix机器可能不会阻止你这样做，但是你的文件系统和几乎所有的应用程序都希望每个用户都拥有一个唯一的UID。 如果你开始走这条路，我可以保证你会遇到问题。 也许不是马上，但最终。 例如，尽pipe显示友好的名称，文件和目录使用UID号码来指定其所有者; 如果遇到有重复UID问题的程序，则不必稍后更改密码文件中的UID，而无需执行一些严重的手动文件系统清理。
sudo是前进的道路。 以root身份运行命令可能会带来额外的麻烦，但是它在访问和审计方面为您提供了一个更加安全的框。
明确的选项2，但使用组来给每个用户尽可能多的控制，而不需要使用sudo。 每个命令前面的sudo都会失去一半的好处，因为你总是处于危险区域。 如果你使相关的目录可以被系统pipe理员写入而没有使用sudo，你可以把sudo返回到exception，这让所有人感觉更安全。
在过去，sudo不存在。 因此，拥有多个UID 0的用户是唯一可用的select。 但是这还不是很好，特别是使用基于UID的日志来获取用户名。
现在，sudo是唯一合适的解决scheme。 忘了别的。
事实certificate这是可以logging的。 BSD unices已经有了很长一段时间的toor帐号，并且bashroot用户倾向于在csh为标准的系统上接受实践（接受的不当行为）
也许我很奇怪，但方法（3）也是首先出现在我脑海里的东西。 优点：你可以让每个用户在日志中input姓名，并且知道谁是root用户。 缺点：他们每个人都是根源，所以错误可能是灾难性的。
我想问你为什么需要所有的pipe理员有root权限。 你提出的所有3种方法都有一个明显的缺点：一旦pipe理员运行sudo bash -l或sudo su -或者这样，你就失去了跟踪谁做什么的能力，然后一个错误就可能是灾难性的。 而且，如果有可能的不当行为，甚至可能会更糟。
相反，你可能需要考虑另一种方式：
这样，martin就能够安全地处理postfix，如果出现错误或行为不当的情况，你只会失去你的postfix系统，而不是整个服务器。
相同的逻辑可以应用于任何其他子系统，例如apache，mysql等。
当然，这是纯粹的理论，可能很难build立起来。 这看起来像是一个更好的方式走了。 至less对我来说。 如果有人试过这个，请告诉我是怎么回事。