☰

RHEL 7 (CentOS 7) security / ssh / sshd_config 建议请求

tag-icon • tag-icon centos rhel security sshd public-key-authentication
RHEL 7 (CentOS 7) security / ssh / sshd_config 建议请求

我不是系统管理员，并尝试创建一个或多或少安全的 Web 服务器（基于 LAMP操作系统7）。
我阅读了一些关于设置初始 CentOS 7 Droplet 的教程，一切都运行良好。

然而，我很难理解我在阅读的文章中读到的一些基本概念，并且需要更多合格人员的一些输入，因为我不确定副作用。

非常感谢您的意见。

设想：
我正在 Digital Ocean 上使用 cloud-init（用户数据）来创建和配置新的 Droplet。据我了解，cloud-init 作为 system/root 运行，创建以下设置，特别是 root 的 ssh_config：

  • 根据该用户的 ssh 密钥 (ssh-authorized-keys) 创建一个新用户（在这种情况下称他为 admin）a
  • 将该用户添加到组 Wheel 并设置 sudo: ['ALL=(ALL) NOPASSWD:ALL']
  • 在 /etc/ssh/sshd_config 中禁用 root 登录
  • 允许用户在 /etc/ssh/sshd_config 中进行管理
  • 在/etc/ssh/sshd_config中设置PasswordAuthentication no
  • 在 /etc/ssh/sshd_config 中设置 PubkeyAuthentication yes 和 RSAAuthentication yes
  • 配置firewalld并执行一些其他任务

问题：

  1. 以管理员身份通过 ssh 连接我的 Droplet 后，相关的 sshd_config 为空。我认为这是因为在创建 Droplet 并运行 cloudconfig 时，cloud-init 作为 system/root 运行。

    1.1 我是否需要在此处设置与为 root 用户创建 Droplet 时相同的设置？ 1.2 如果是这样，多个 ssh_config 文件有什么意义？

  2. 查看 cloud-init 日志文件，我发现为 root 创建了一个公共/私有 rss 密钥对。
    相关密码已邮寄给我，因为我决定不为 root 用户提供初始 ssh 密钥（仅用于测试目的）。
    但是，在新创建的用户 adminls -a上运行 /会显示：etc/ssh

    . moduli sshd_config ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub .. ssh_config ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key

    例如，查看 ssh_host_rsa_key，它包含为 root 用户创建的相同 ssh 密钥。

    2.1为什么我称为 admin（而不是 root）的新创建用户在 ssh 文件夹中拥有与 root 相同的密钥？

    2.2是因为我将他添加到组wheel和sudo：['ALL =（ALL）NOPASSWD：ALL']吗？是推荐的吗？

    2.3如果另一个用户帐户可能受到损害并且还拥有使黑客成为非常幸运的人所需的所有密钥，那么禁止 root 通过 ssh 远程登录有何意义？目的只是为了让用户的名字更难猜吗？

  3. 我了解某些操作仍然需要 sudo / root 权限。如果以管理员身份登录，我可以使用 su root 更改为 root。

    3.1当我在 /etc/ssh/sshd_config 中禁用 root 登录（仅适用于 ssh，对吧？）但创建的新用户（admin）具有相同的权限并且可以轻松切换到 root 时，我问自己可以采取什么措施来确保安全该密码更好，或者是否有诸如双因素身份验证之类的东西可以增加安全级别？

    3.2.另一方面，我不明白如果成功获得管理员帐户控制权的黑客可以轻松读取 root 的 ssh 密钥（请参阅上面的上一个主题）并绕过任何安全层，那么这如何能达到更好的安全级别？

简而言之：我非常喜欢我正在阅读的内容，但是在查看文件系统时，特别是在我使用 cloud-init 创建的用户 ssh 文件夹中找到根 ssh 密钥（私有和公共）之后，我有点担心误解了什么。

顺便说一句：这是我的 cloud-init 脚本：

#cloud-config

# log all cloud-init process output (info & errors) to a logfile
output: {all: ">> /var/log/cloud-init-output.log"}

# final_message written to log when cloud-init processes are finished
final_message: "System boot (via cloud-init) is COMPLETE, after $UPTIME seconds. Finished at $TIMESTAMP"

package_upgrade: true

users:
  - name: admin
    groups: wheel
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash
    ssh-authorized-keys:
      - ssh-dss AAAABBBBBCCCCDDDD...
runcmd:
  - sed -i -e 's/#Protocol 2/Protocol 2/g' /etc/ssh/sshd_config
  - sed -i -e 's/#LoginGraceTime 2m/LoginGraceTime 2m/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
  - sed -i -e 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
  - sed -i -e 's/#RSAAuthentication yes/RSAAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers admin' /etc/ssh/sshd_config
  - service sshd restart

  #firewall
  - systemctl start firewalld
  - firewall-cmd --permanent --add-service=ssh
  - firewall-cmd --reload
  - systemctl enable firewalld

答案1

不是大多数问题的答案，但评论太长：

  1. 拥有单独用户（无论是“admin”还是其他用户）的原因正是为了在图片中再添加一层身份验证/授权（使用密钥/密码以用户身份登录，然后输入另一个密码以成为 root） 。除非用户具有与 root 相同的 UID，否则它不具有与 root 相同的权限，尽管它可能比“普通”用户拥有更大的权限。

    它还允许不同的用户访问同一帐户 - 一个帐户可以通过不同的密钥进行身份验证。当您拥有多个用户（和多台机器）时，这会让事情变得更容易 - 撤销一个特定用户的权限而不打扰其他用户只是从文件中删除一个条目AuthorizedKeys（通常是 ~/.ssh/authorized_keys`。（显然同样适用）用于直接根访问，但没有额外的身份验证/授权级别。）

    至于攻击者的密钥可用性：只有密钥的公共部分（必须）保存在服务器上。在身份验证阶段，客户端使用他的私钥，但不会将其留在服务器上的任何位置。因此，无论谁在服务器上获得了root权限，仍然无法获得以普通用户身份远程登录的能力（这不会将他的私钥保留在所述机器上）。

    对于其他事情，通常是这样的：
    问：“你如何称呼在你的系统上获得 root 权限的人？”
    A：“是的先生。”

  2. 通过在命令行前添加“sudo”来允许任何用户以 root 权限运行任何命令是对sudo.虽然有些人认为这是一个好主意，但从安全角度来看，这是最愚蠢的事情之一，因为它实际上使每个人都成为系统管理员。唯一的优点是，人们不会意外地rm -Rf /以提升的权限运行（就像root直接登录一样）。但随后肌肉记忆开始发挥作用，人们开始sudo在任何地方使用，剩下的唯一优势就是可以记录命令。正如您正确注意到的那样，它也违背了辅助帐户的目的。

    简而言之：ALL=(ALL) NOPASSWD:ALLTM是个坏主意，在服务器上加倍。请不要这样做。

    一旦你摆脱了这一点，突然间，第 1) 部分就开始变得更有意义了。

答案2

CentOS 7 安全强化我刚刚发布的文档可能会对您有所帮助，它基于 OpenSCAP。

相关内容