我正在尝试保护我们服务器上一个名为 ssh_user 的帐户,该帐户仅用于通过 SSH 连接到我们的服务器。我们团队中的每个人都通过 PSK 安全的 ssh 连接登录此帐户,并通过隧道连接到我们版本控制系统的特定端口。每个人都在文件 /etc/ssh/ssh_user/authorized_users 中拥有自己的 PSK,从而确保了安全性
ssh_user 帐户是使用以下方式创建的:sudo adduser -r -s /bin/sh ssh_user使用户成为系统帐户,没有主目录并且 shell 尽可能受到限制。
虽然这些已经是受信任的用户,但始终存在对该帐户真正需要的访问权限的担忧,因为我仍然可以通过该帐户列出根文件系统中的目录,并读取 /etc/ssh/... 下的配置文件,所以我想知道这个问题是否像发出撤销整个文件系统中对组“其他”的所有访问权限一样简单sudo chmod go-rwx/*? 但我不知道这会对默认的 Ubuntu 16.04 安装造成什么影响(如果有的话)。
我绝不是 Linux 或安全方面的专家,而且我也不会假装知道自己在做什么,因此非常感谢任何意见。
谢谢!
答案1
跟我重复一遍:/
在不知情的情况下运行任何权限命令确切地你正在做的事情是破坏系统的好方法。即使你知道自己在做什么,这仍然可能是错误的事情。
就您而言,该命令不起作用,因为它启动错误。其次,组是 Linux 中非常有效的用户构造,阻止组访问文件是一个非常糟糕的主意。
如果我理解正确的话,您希望阻止用户访问他们无权阅读的资源。幸运的是,有几种方法可以做到这一点,每种方法都有利弊。
选项 1:根本不使用 Shell(最佳方法)
你使用 SSH 允许用户通过隧道进入安全服务器,对吧?在这种情况下,用户为什么还需要 shell?只需阻止他们对 shell 的访问,然后只允许它们挖隧道!
为此,只需创建一个名为noaccess
或类似名称的新组。然后,将以下内容复制并粘贴到您的/etc/ssh/sshd_config
文件中:
Match Group noaccess
AllowTcpForwarding yes
X11Forwarding no
如果你想平衡更多的安全限制他们可以挖隧道的地方,您可以将参数添加PermitOpen
到 SSH 配置中。例如,如果您只想允许用户转发到当前服务器上的端口 1337,则可以PermitOpen localhost:1337
在配置文件中添加AllowTcpForwarding
该指令,如下所示:
Match Group noaccess
AllowTcpForwarding yes
PermitOpen localhost:1337
X11Forwarding no
...
/bin/true
最后,通过运行命令将用户的 shell 设置为chsh -s /bin/true <username>
。如果用户尝试启动任何类型的交互式会话,他们将被默默地(强制地)踢回。如果您想包含“友好”的错误消息,您可以创建一个快速而粗略的“假”shell,它将返回错误消息。
当 SSH 无法访问 shell 时,它会相当恼火,因此您需要将命令行参数传递-N
给 OpenSSH 命令,如下所示:
ssh [email protected] -N -L 3307:localhost:3306
如果您使用 PuTTY,请确保选中突出显示的复选框:
我已经做了一个非常简单的(未经测试) shell 会返回错误消息,同时保持终端窗口打开,这样-N
就没有必要了。您可以找到源代码这里如果您想编译并使用它。即使这样,您仍然应该使用-N
,但它不再是绝对必要的。
选择 2:顺其自然
Linux 中的用户已经拥有相当可接受的权限集。他们可以读取与他们相关且对系统功能很重要的文件。同时,“受保护”的文件(如私钥和
/etc/shadow
)已经不允许未经授权的用户读取。
如果你的用户已经值得信赖(并且确实会在你的系统上工作),那么这是最好的选择——代价是让用户远离他们不属于的地方
选项 3:选择性定位
如果选项 2对于您的需求来说,仍然太不安全,您可以删除chmod o-rwx
您不希望他们访问的文件。这些文件的示例包括“安全”配置文件。但是,您必须非常小心,不要导致服务和应用程序失去对执行其工作所需的文件的访问权限。
您还可以使用访问控制列表阻止用户组访问文件,而无需将他们设置为所有者组。不过,我要提醒大家,这相当复杂,并且如果用户发现被屏蔽的用户不在被屏蔽组中,则他们有办法“逃离”他们所受的约束。
选项 4:chroot
使用chroot
允许您精确控制用户有权访问的内容。您可以决定哪些权限、哪些命令等等。这是一种非常复杂的方法,需要大量工作才能正常工作,因此不建议每个人都使用。
如果你有兴趣,这个问题解释得相当好。