Ubuntu系统使用securetty控制root用户可登录的终端设备

在Ubuntu服务器运维中，/etc/securetty 这个文件是PAM（可插拔认证模块）体系中一个极其重要却常被忽视的防线。它直接决定了root用户能从哪些终端设备登录系统。默认情况下，Ubuntu系统通常只允许root在控制台设备如tty1到tty6上登录，而禁止通过SSH远程终端或串行端口直接获取root权限。这不是系统的漏洞，而是一种强制性的安全策略，目的是切断远程暴力破解root密码的直接通路。

当root用户尝试登录时，login程序或sshd等登录服务会调用pam_securetty.so模块。这个模块会读取/etc/securetty文件的内容，将当前登录所使用的终端设备名与文件中的列表进行比对。如果设备名存在于文件中，root登录被允许；如果不存在，登录请求被直接拒绝，即使密码正确也无法进入系统。这个检查发生在密码验证之后、会话建立之前，是一道额外的访问控制层。值得注意的是，这个机制只对root用户生效，普通用户完全不受影响。

终端设备名在Linux中遵循特定的命名规则。物理控制台通常表示为tty1、tty2等，虚拟控制台对应/dev/tty1到/dev/tty63。串行端口使用ttyS0、ttyS1这样的名称。伪终端则使用pts/0、pts/1等动态分配的名称。SSH登录时，系统会为每个会话分配一个伪终端，这就是为什么即便你把pts/0加入securetty文件，也无法保证下次SSH登录时root能通过，因为终端序号是动态变化的。

直接使用cat命令就能查看文件内容。在大多数Ubuntu 20.04或22.04的默认安装中，你会看到类似这样的输出：

# /etc/securetty: list of terminals on which root is allowed to login.
# See securetty(5) and login(1).
console
tty1
tty2
tty3
tty4
tty5
tty6

这里的console是一个特殊的设备名，它通常指向系统实际使用的物理控制台设备。在某些嵌入式系统或虚拟机环境中，console可能映射到ttyS0或hvc0。tty1到tty6对应的是可以通过Ctrl+Alt+F1到F6切换的虚拟终端。注意到文件中没有任何pts伪终端条目，也没有ttyS串行设备条目，这就是为什么默认情况下你无法直接用root账号通过SSH登录Ubuntu系统。

如果你发现某些云服务器或VPS的Ubuntu镜像允许root直接SSH登录，通常有两种可能：要么是securetty文件中被添加了pts/0之类的条目，要么是SSH服务的配置中PermitRootLogin被设置为yes，并且PAM的sshd配置文件里根本没有调用pam_securetty.so模块。后者是更常见的情况，很多云服务商会为了用户方便而绕过这个限制。

要修改root可登录的终端列表，需要用root权限编辑这个文件。使用sudo vim /etc/securetty或sudo nano /etc/securetty都可以。文件格式非常简单，每行一个终端设备名，不需要写/dev/前缀。以#开头的行为注释。修改时需要注意以下几点：

第一，不要删除console这一行。很多系统的启动脚本和救援模式依赖console设备，删除它可能导致在单用户模式或紧急shell中无法登录root，这在系统故障恢复时会造成灾难性后果。

第二，添加串行终端时要谨慎。如果你的服务器连接了串行控制台服务器或者使用了IPMI的串行重定向功能，添加ttyS0可以让管理员通过串行线路登录root。但这也意味着任何能物理接触到串行端口的人都可以尝试登录。在数据中心环境中，这通常是可以接受的风险，因为物理访问本身已经意味着高权限。添加时写入ttyS0即可，如果有多个串行端口，依次添加ttyS1、ttyS2等。

第三，关于伪终端pts的处理。绝对不要试图通过添加pts/0、pts/1等具体序号来允许SSH登录root。伪终端的序号是内核动态分配的，每次登录都可能不同。正确的做法是，如果你确实需要通过SSH使用root，应该用普通用户登录后使用sudo或su命令提权，而不是开放root的直接SSH登录。这是Linux安全实践的基本原则。

securetty文件本身只是一个静态列表，真正执行检查的是PAM模块。在Ubuntu系统中，与登录相关的PAM配置文件位于/etc/pam.d/目录下。login服务的配置在/etc/pam.d/login文件中，通常会包含这样一行：

auth [success=ok default=ignore] pam_securetty.so

这行配置的意思是：如果pam_securetty.so模块检查通过，认证继续；如果检查失败，这一行被忽略，认证流程继续执行其他模块。这种配置方式比较温和，securetty检查失败不会直接导致登录被拒，后续的其他认证模块仍然可以发挥作用。但在某些加固过的系统中，你可能会看到更严格的写法：

auth requisite pam_securetty.so

requisite关键字意味着一旦这个模块返回失败，整个认证流程立即中断，root登录被直接拒绝。这种配置提供了更强的安全保障。你可以根据实际安全需求调整这个控制标志。

对于SSH服务，情况略有不同。Ubuntu的/etc/pam.d/sshd文件中默认可能根本没有引用pam_securetty.so模块。这意味着即使你在securetty文件中做了各种配置，对SSH登录也完全不起作用。要让securetty对SSH生效，需要在/etc/pam.d/sshd文件中添加对pam_securetty.so的调用。但这里有一个技术细节需要注意：SSH分配的伪终端名称是动态的，而securetty文件是静态列表，两者天然不兼容。因此，在sshd的PAM配置中添加pam_securetty.so通常只会导致root完全无法通过SSH登录，而这恰恰是推荐的安全策略。

在日常运维中，securetty的配置应该遵循最小权限原则。物理控制台的tty1到tty6保持开放是合理的，因为能接触到物理控制台的人通常已经具备了物理访问权限，限制root登录意义不大。但对于任何形式的远程访问，包括SSH、Telnet、串行端口等，都应该默认禁止root直接登录。

如果你管理着大量通过串行控制台访问的服务器，可以考虑在securetty中添加ttyS0，但同时必须配合其他安全措施。例如，在串行控制台服务器上设置强密码和访问日志，或者使用带外管理系统自带的认证机制。单独依赖securetty一个文件来保护root安全是不够的，它应该是纵深防御体系中的一层。

对于容器化环境或LXC/LXD容器，情况比较特殊。容器内部的console设备可能映射到宿主机的不同设备文件。如果你在容器中运行Ubuntu，securetty文件通常由容器模板提供，默认配置可能与物理机相同。在容器中修改securetty时，要确认console设备在容器运行时环境中的实际映射情况，避免把自己锁在容器外面。

当你修改了securetty文件后，发现root无法在预期的终端上登录，可以从以下几个方向排查。首先检查文件权限，/etc/securetty应该属于root用户，权限通常设置为644或600。如果文件不可读，PAM模块会将其视为不存在，导致所有终端都被允许或者全部被拒绝，具体行为取决于PAM模块的版本和配置。

其次检查PAM日志。在Ubuntu中，认证相关的日志通常记录在/var/log/auth.log中。当你尝试root登录失败时，可以看到类似这样的日志条目：

login: pam_securetty(login:auth): access denied: tty 'pts/1' is not secure !

这条日志明确指出了被拒绝的终端设备名和原因。通过查看日志，你可以快速判断是securetty配置问题还是其他认证模块导致的问题。

还有一个容易被忽略的细节：在某些Ubuntu版本中，如果/etc/securetty文件不存在，pam_securetty.so模块的默认行为是允许root从任何终端登录。这个行为可能因PAM版本和编译选项不同而有所差异。因此，如果你想要严格限制root登录，首先要确保这个文件存在且内容经过仔细审核，而不是简单地删除文件了事。

在现代Ubuntu系统中，systemd-logind负责管理用户登录会话和终端设备。当你通过Ctrl+Alt+F3切换到tty3时，systemd-logind会创建一个登录会话，并将终端设备标记为seat0的一部分。securetty的检查仍然基于传统的设备文件名，与systemd的会话管理并不冲突。但有一个值得注意的变化：在systemd环境中，/dev/console可能是一个指向实际控制台设备的符号链接，而securetty文件中写的console会被PAM模块正确解析为实际设备。这意味着即使你的系统使用串行控制台作为主控制台，只要securetty中有console这一行，root就能在串行控制台上登录。

对于使用图形界面的Ubuntu桌面版，从GDM或LightDM登录管理器登录时，通常不会触发pam_securetty检查，因为图形登录走的是显示管理器的PAM配置，而不是login的配置。这也是为什么你可以在桌面版Ubuntu中直接以root身份登录图形界面，只要你在安装时设置了root密码并且显示管理器允许root登录。这个行为与服务器版的文本控制台登录形成对比，是很多管理员在加固桌面系统时容易忽略的安全盲区。

在批量管理Ubuntu服务器时，通过Ansible、Puppet或Chef等工具统一配置securetty是推荐的做法。一个典型的Ansible任务可以这样写：

- name: Configure securetty for root access control
  copy:
    dest: /etc/securetty
    content: |
      console
      tty1
      tty2
      tty3
      tty4
      tty5
      tty6
      ttyS0
    owner: root
    group: root
    mode: '0600'

这个任务将securetty文件统一设置为包含物理控制台和第一个串行端口，同时将权限收紧为600。通过版本控制系统管理这个配置，可以确保所有服务器遵循相同的安全基线。当需要临时开放某个终端时，通过配置管理工具进行变更，而不是手动登录每台服务器修改，这样既能保证一致性，也留下了审计记录。

在云原生环境中，如果使用自定义的Ubuntu AMI或容器镜像，应该在镜像构建阶段就设置好securetty文件。对于需要符合CIS基准或等保合规要求的系统，securetty的配置是必查项。CIS Ubuntu Linux基准中明确要求确保/etc/securetty文件存在且权限正确，并且只包含console和本地tty设备。

securetty机制体现的是Unix/Linux安全体系中一个核心思想：root账户不是用来日常使用的。root应该只在必要的系统管理任务中通过受控的途径使用。物理控制台被视为相对安全的上下文，因为物理访问本身就是一道屏障。而网络连接、串行线路等被视为不安全的上下文，因为攻击者可能从远程发起攻击。这种基于上下文的安全模型，在当今零信任架构盛行的时代仍然具有现实意义。

很多初学者觉得限制root登录很麻烦，倾向于直接开放所有终端。这种想法忽略了纵深防御的重要性。即使你的root密码足够复杂，即使你配置了fail2ban来防止暴力破解，多一层securetty的保护总是更安全。安全不是单点防御，而是多层次的组合。当某一层防护被突破时，其他层次仍然能够提供保护。securetty就是这样一个简单却有效的额外层次，它的配置只需要几分钟，却能在关键时刻阻止未授权的root访问。