为什么“bin”用户需要登录shell？

Question

在/var/log/auth.log对我的一个公共网络服务器进行审计时，我发现了这一点：

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

乍一看，这看起来像是ssh来自随机黑客的典型登录垃圾邮件；然而，当我仔细观察时，我注意到了别的东西。大多数失败的/var/log/auth.log条目都invalid user在其中说，就像这样：

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

关于失败登录消息令人不安的事情bin是，它是一个有效的用户中/etc/passwd，即使有一个登录shell：

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

我想我已经覆盖了所有的默认用户名时，我关闭，可以远程登录PermitRootLogin的/etc/ssh/sshd_config; 发现这个条目在我偏执的头脑中打开了新的可能性。如果服务以某种方式在 下运行bin，那么远程可能有人可以以某种方式将 ssh 密钥bin从盒子上正在运行的服务插入到用户的目录中，所以bin如果可能的话，我想完全禁用用户的登录。

问题

• 这台服务器是远程的，而且维修费用很高（即我将支付远程手连接 KVM 的费用，以及 KVM 的租金）。我试图弄清楚如果我将/etc/passwd条目更改为如下所示，我可能会破坏什么bin：

  bin:x:2:2:bin:/bin:/bin/false

• 我运行了以下命令试图找出bin需要什么......但是，这些命令没有提供任何文件，我找不到bin. bin无论如何，用户做什么？

  $ sudo find / -group bin

  $ sudo find / -user bin

• 是否还有其他用户应该将其登录 shell 设置为/bin/false？仅供参考，我已经有/bin/false上www-data。

• 我是不是太偏执了？

如果这很重要，我正在运行 Debian。

Answer 1

拥有有效 shell 且没有密码的用户仍然可以通过非基于密码的方法登录，最常见的是 ssh 密钥。运行 cron 作业需要有效的 shell。一个有效的 shell 也是必要的su bin -c 'wibble'（至少在 Linux 上，su bin -s /bin/sh -c 'wibble'也可以工作）。

在 的情况下bin，大多数系统不会像bin正常操作那样运行命令，因此将 shell 设置为/bin/false就可以了。

没有任何允许bin通过 SSH 登录的直接攻击的风险，因为这需要/bin/.ssh/authorized_keys以用户bin或 root 身份创建。换句话说，进入的唯一途径就是进入。但是，拥有有效的外壳确实会增加错误配置的风险。它还可以允许使用 SSH 以外的服务进行一些远程攻击；例如，用户报告攻击者可以daemon通过 Samba 远程设置密码，然后使用该密码通过 SSH 登录。

您可以通过在DenyUsers指令中列出系统用户的名称来堵住 SSH 漏洞/etc/ssh/sshd_config（不幸的是，您不能使用数字范围）。或者，相反，您可以放置​​一个AllowGroups指令，只允许包含物理用户的组（例如，users如果您授予所有物理用户该组成员资格）。

在 Debian ( #274229 , #330882 , #581899 ) 中存在关于此问题的错误，目前打开并归类为“愿望清单”。我倾向于同意这些是错误，系统用户应该将其/bin/false作为他们的 shell，除非似乎有必要这样做。

Answer 2

作为用户，您不必担心这些。他们是安全组意义上的“用户”，而不是“登录和使用”意义上的用户。如果您查看“/etc/shadow”，您将看到所有这些“用户”都没有密码（“x”或“！”，而不是长盐哈希）。这意味着这些用户无论如何都无法登录。

也就是说，我不知道将所有这些用户的“/bin/sh”更改为“/bin/false”是否是个好主意。由于程序在这些组下运行，因此可能不允许它们执行所需的命令。我将它们保留为“/bin/sh”。

您无需担心这些用户。只担心您创建的用户（以及在“/etc/shadow”中带有哈希值的用户）