我创建了一个 Debian 不稳定容器debootstrap并使用 运行它systemd-nspawn.service。
我可以使用 root 身份登录machinectl login，但不能同时登录多次。当我运行第二次登录时，一输入就拒绝root；它不会提示输入密码。
正如您所料，如果我查看系统日志，它会显示访问被拒绝，pam_securetty因为 tty /dev/pts/2“不安全”。这提出了几个问题。
- 第一次登录如何
/dev/pts/0被认为是安全的？ - 为什么
/dev/pts/1第二次登录时没有使用？ - 默认的 /etc/securetty 似乎列出了每种类型的 tty - 包括可以连接到调制解调器的串行线？我可以想象排除伪终端的原因。但是，如果你允许全部物理终端的类型，这个练习的意义何在？！为什么不使用一组不允许以 root 身份登录的（短）tty 类型来工作？除了伪终端之外，是否有任何东西被故意从列表中省略，默认情况下需要被阻止？如果是故意遗漏那为什么不评论呢？
我能够回答问题1。无法形容的可怕答案是，在 Debianstretch（9-testing，login-4.4-4）中，/etc/securetty 包含 /dev/pts/0 和 /dev/pts/1，但不包含 /dev/pts/2。可以猜到这是专门为了支持而添加的systemd-nspawn。其中之一是正确的。但这只会让我更加困惑这些设置应该完成什么！
答案1
这意味着设置没有任何意义。
显然，支持串行安装的发行版希望能够允许第一个串行控制台。您的问题是为什么最初的 Debian 开发人员认为启用 pam_securetty 很有用，但将其配置为允许每种类型的 tty。因此，什么会阻止发行版使用更简单的设置。
Poettering 提出了一个答案：分布应该使用更简单的设置，因为 securetty 使用的分类系统已过时。
https://github.com/systemd/systemd/issues/852#issuecomment-127759667
它来自 tty 名称静态的时代。但如今，最少的 tty 实际上是老式的主板串行端口。几乎所有这些都是通过 USB 插入的或者是伪 tty。无论哪种方式，它们的名称都没有像 /etc/securetty 所期望的那样固定，因此整个概念已经过时了。
因此：请要求您的发行版停止在默认启用 pam_securetty 的情况下发货，这确实已经成为过去。同时，从 /etc/pam.d/* 中的所有文件中手动删除它，或者将所有潜在的当前和未来 pty 添加到 /etc/securetty。
https://github.com/systemd/systemd/issues/852#issuecomment-128564307
您只需从容器中删除 /etc/securetty 即可允许 root 在所有 tty 上登录。