您如何管理服务器？ 根密码
在我们的管理团队中，每个人都拥有所有客户端服务器的 root 密码。 但是，如果其中一名团队成员不再与我们一起工作，我们该怎么办？ 他仍然拥有我们的密码，每次有人离开我们时，我们都必须更改所有密码。
现在我们使用 ssh 密钥而不是密码，但如果我们必须使用 ssh 以外的其他东西，这就没用了。
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我运行的系统只有 sudo 策略。 即，root 密码是
*（禁用），人们必须使用 sudo 才能获得 root 访问权限。 然后，您可以编辑sudoers文件来授予/撤销人们的访问权限。 它非常精细，并且具有很多可配置性，但具有合理的默认值，因此您不会花很长时间进行设置。The systems I run have a sudo-only policy. i.e., the root password is
*(disabled), and people have to use sudo to get root access. You can then edit yoursudoersfile to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.我通常会建议如下：
现在，通过此设置，所有用户都必须使用 sudo 进行远程管理，
但当系统严重混乱时，就没有办法寻找
用于解锁控制台的 root 密码。
编辑：提供自己的登录名的其他系统管理工具也需要调整。
I would normally suggest the following:
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
虽然像 Chris 建议的那样使用仅限 sudo 的策略是一个好主意，但 LDAP 方法也可能会有所帮助。 我们通过包含所有 root 密码的文件来补充这一点，但 root 密码确实很长且难以记忆。 虽然这可能被认为是一个安全缺陷，但它允许我们在 LDAP 服务器关闭时仍然可以登录。
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
除了可能更好的 sudo 策略之外，每个管理员没有理由不能拥有自己的 UID 0 帐户，但名称不同，密码不同，甚至主目录不同。 当他们离开时，只需删除他们的帐户即可。
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
我们只是让更改我们管理的每台计算机上的 root 密码变得非常容易，因此当人们离开时我们只需运行脚本即可。 我知道我不太精明，但它确实有效。 在我之前，公司中的每个人都可以在所有服务器上访问 root 权限。 幸运的是我们摆脱了这一点。
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
一般来说，如果有人离开我们的团队，我们不会费心去更改 root 密码。 他们要么离开了公司（并且无法再访问这些机器，因为他们的 VPN 已被撤销，他们对大楼的访问权限以及对网络的无线访问权限也被撤销），或者他们在公司内部的另一个部门并具有不破坏我们环境的专业精神。
这是一个安全漏洞吗？ 或许。 但实际上，如果他们想破坏我们的环境，他们就会在继续前进之前这样做。
到目前为止，任何离开团队想要再次访问我们的机器的人总是会请求许可，即使他们可以在没有许可的情况下继续使用。 我不认为有任何理由阻碍我们完成工作的能力，也就是说，没有理由相信其他人会采取不同的做法。
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
相当强的 root 密码。 每个盒子都不一样。 没有远程 root 登录，也没有登录密码，只有密钥。
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
如果您通过证书具有 ssh 访问权限，那么当您使用 ssh 登录并通过
passwd或sudo passwd更改root密码时，是否无法使用需要做其他需要密码的事情吗？If you have ssh access via your certificates, can't you log in via ssh and change the
rootpassword viapasswdorsudo passwdwhen you need to do something else that requires the password?在我工作的地方，我们使用仅 sudo 策略，但 root 密码仍然保留。 root 密码仅可供少数员工使用。 我们有一个名为“Password Manager Pro”的程序，它可以存储我们所有的密码，并且还可以提供密码审核。 这使我们能够返回并查看哪些用户访问了哪些密码。 因此，我们只能更改实际需要更改的密码。
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH 密钥没有真正的替代方案。
为了管理许多服务器上的许多
authorized_keys文件，如果您不希望每台服务器上都有相同的文件，则必须实现自己的解决方案。 要么通过自己的工具，要么使用一些配置管理解决方案，如 puppet、ansible 或类似的东西。否则，
bash中的 for 循环或某些clush操作就足够了。除了 SSH 登录之外的任何内容：
对于您运行的基于登录的服务，请使用某种带有中央后端的身份验证。 请记住，如果此后端不可用，没有人会做任何工作！以
集群方式运行服务。
不要使用超级骗子服务后门帐户进行黑客攻击，以便在出现问题时始终保持访问权限（例如由于配置错误而导致管理员访问权限被破坏）。 无论您如何监控影响此帐户的访问或配置更改，这都是“糟糕的”(TM)。
与其让这个后门正确，不如只对应用程序进行集群，或者至少有一个备用系统，在主机死机时定期镜像手头的设置，然后可以通过网络中的路由更改轻松激活它。 如果这听起来太复杂，那么您的企业要么太小，您可以忍受半天到两天的停机时间。 或者，由于缺乏知识，您真的很讨厌集群，并且只是在错误的事情上进行节省。
一般情况：如果您确实使用无法与某种 Active Directory 或 LDAP 集成一起使用的软件，您必须立即行动并手动更改这些软件的密码。
还有一个专用的密码管理数据库，只能由极少数人直接访问，并且对所有其他人都是只读的，这非常好。 不要理会 Excel 文件，这些文件缺乏适当的权限管理。 在 .csv 文件上使用版本控制在达到一定阈值后也不会真正减少它。
SSH keys have no real alternative.
For management of many
authorized_keysfiles on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.Else a for loop in
bashor someclushaction will suffice.Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.