摘要

  • 1991 年的 RFC 1258 把 BSD rlogin 描述为广泛使用的既有实现，而非 Internet 标准。连接开始时会送出一个空字段、客户端用户名、服务器用户名和终端类型/速率。
  • rlogin 可以由受信用户或受信主机免去密码输入。RFC 明言：一台受信主机失陷可波及所有如此配置的系统；受信主机通常由主机名指定，DNS、网络或可写的信任清单各自都可能改变这项本地决定的依据。

四个字符串只是把请求说清楚

rlogin 的开场很短。TCP 连接建立后，客户端依次送出四个以空字符结束的字符串：先是一个空字符串，再是客户端用户名、服务器用户名以及终端类型和速率。服务器返回一个零字节，表示它已经收到这些字符串并进入数据传输阶段。

这组字段很容易被误当成一份完整的身份叙述。两边都有用户名，目标账户写得明确，服务器也作出了回应，随后终端开始工作。但它们并不回答同一个问题。客户端用户名是客户端提交的名字；服务器用户名是它请求的账户；终端信息说明显示如何协作；零字节只说明开场字段已经收到、协议进入下一阶段。

RFC 1258 的地位本身提醒读者不要把这些字段抬高。它记录的是已有且常见的实现，不是把这一交换规定为 Internet 身份认证标准。该协议让 Unix 主机之间能传递较多终端语义，这解释了它的实用性；却没有让一串名字独自证明谁在操作发送主机、谁有权进入账户，或后续会话是否产生了某个结果。

“受信”是服务器的本地决定

真正让密码提示消失的不是起始字符串，而是接收端配置的受信关系。RFC 1258 说，用户可以列出受信用户和/或受信主机，使其无需输入密码就以该用户身份登录。这是一条本地准入规则，不是一张随连接自动携带的证明书。

文中尤其指出，受信主机的说明通常是一项主机名。名称可以是定位和管理的好工具，也可以成为策略输入；但被写进清单的名称并没有把解析结果、网络路径、实际机器和键盘前的人合成一个已核验事实。若组织的域名服务器或网络遭到破坏，不受信的主机可能伪装成受信系统。RFC 没有把这一句写成某个单位发生过的事件，它只是拒绝把以主机名为依据的便利说成自足的认证。

另一层是清单本身的保管权。用户的受信登录文件若意外对其他用户可写，便可能出现不可信的新增条目。此时，连接仍可看上去格式正确，服务器也仍可发出进入数据模式的回应；真正决定免密入口的记录却可能已被改写。报文的可见性和配置的完整性不是同一项证据。

一条方便的边会扩展成一张风险图

RFC 1258 对范围的描述比一般的安全警语更具体：若一个受信主机被攻破，所有配置为信任它的系统都会被打开。关键不只是“少输了一次密码”，而是一个局部设置把后果接到了更多机器上。

单看每一条配置，事情都很小：一台工作站、一份用户名列表、一台认为它熟悉来源的服务器。放在一起，这些边界形成了一张准入图。第一台主机的失陷会对没有直接改动的机器产生意义，因为它们接受同一来源所带来的继承性主张。

RFC 提到一种较窄的安排：从一台工作站进入其他常用系统，而非让所有系统彼此免密。这不是把某台机器变成了可认证的身份，也不是对风险的保证。它说明的是，风险范围取决于信任边如何连接，而不是取决于单次登录体验有多顺滑。

终端可用不等于前提已经成立

rlogin 处理远端回显、流控、窗口变化、输出刷新和本地转义。这些细节使会话看起来像本机终端的延续。可用的终端流最多表明某个交换进入数据阶段、字节按协议被处理；它不能倒推出受信清单的作者有权修改、名称仍指向预期主机、或免密条件仍然正当。

RFC 1258 还提到 Kerberos 等安全认证扩展能够在保留便利的同时降低失陷可能。这不是说 rlogin 的四个开场字段已经包含了此类认证；恰恰相反，它保留了当时人们已看见的空层：便利的来源规则与较强的身份依据之间仍有距离。

来源与证据限制

本文只使用 RFC 1258 — BSD Rlogin。它支持 1991 年文件状态、终端协议、当时的 TCP 联络端口、开场字段、数据模式回应、受信主机免密以及名称、网络、可写清单和认证扩展的警示。它不能证明今天仍有部署、端口的当前状态、某个主机被攻破、某人的身份、某项授权或一次会话的业务结果。