rsh 命令详解：连接远程主机执行命令的经典远程 Shell 工具

rsh（remote shell）是 Linux/Unix 系统中经典的远程命令执行工具，用于连接指定的远程主机并直接执行命令，而无需先建立交互式登录会话。本文基于 Linux 命令大全仓库中的 rsh 手册页，系统讲解 rsh 的语法、选项、参数、认证机制与服务端配置，并结合仓库中 rcp、rsync、tar 等关联命令说明 rsh 在真实场景中的底层角色，帮助你完整掌握这一"远程 shell"工具的用法与局限。

命令概述与语法

rsh 的工作方式与 ssh 相似：客户端连接远程主机的 rsh 服务（rshell 守护进程），提交命令后由远程端执行并将结果返回本地。与 rlogin（从当前终端登录远程主机）不同，rsh 的核心定位是"连接远程主机并执行指定命令"，适合脚本化、批量化的远程操作。

其基本语法为：

rsh(选项)(参数)

即：

rsh [-dn] [-l 用户名称] 远程主机 [指令]

其中 远程主机 是必须给出的连接目标，指令 是可选的远程待执行命令。如果省略指令，rsh 在部分实现中会退化为类似 rlogin 的登录行为；指定指令时则执行完毕后立即返回。

选项详解

根据 rsh 手册页，rsh 支持以下三个核心选项：

选项	作用
-d	使用 Socket 层级的排错（debug）功能，在连接建立与数据收发过程中输出底层 Socket 调试信息，适合排查连接失败、认证失败等网络层问题
-l<用户名称>	指定登录远端主机所使用的用户名称；未指定时默认使用本地当前用户名
-n	把标准输入（stdin）重定向到代号为 /dev/null 的特殊外围设备，避免本地终端输入干扰远程命令的执行

使用示例：

# 以 root 身份连接远程主机 192.168.1.10 并执行 date 命令
rsh -l root 192.168.1.10 date

# 开启 Socket 层调试
rsh -d webserver1 hostname

# 丢弃标准输入，适合在脚本中调用
rsh -n webserver1 uptime

参数说明

rsh 接受两个位置参数：

• 远程主机：指定要连接的远程主机，可以是 IP 地址或主机名（域名）。主机名通常需要在本地 /etc/hosts 或 DNS 中能够解析；
• 指令：指定要在远程主机上执行的命令。该命令会在远程端由 shell 解释执行，其标准输出与标准错误会回传到本地终端。

如果省略指令，rsh 将进入交互式登录流程；只要给出指令，rsh 就执行命令并直接返回退出码，因此非常适合嵌入脚本完成"批量在 N 台机器上执行同一命令"的场景。

认证机制：.rhosts 与 hosts.equiv

rsh 的认证采用基于信任主机列表的机制，这也是它与 ssh（基于密钥）最本质的区别：

• 远程主机的 /etc/hosts.equiv 文件列出了受信任的主机，文件中记录的主机名对应的用户，可以免密直接访问；
• 每个用户的 ~/.rhosts 文件列出了该用户信任的"主机 + 用户"组合，格式为 主机名 用户名。

当 rsh 发起连接时，远程 rshd 守护进程会检查来源主机与用户名是否出现在上述两个文件中，命中则直接放行。由于整个流程基于明文信任且 rsh 协议本身不对数据进行加密，任何能伪造来源 IP 的机器都可能绕过认证，这是 rsh 家族命令（rsh、rlogin、rcp）被现代系统弃用的根本原因。

服务端配置（以 Red Hat / xinetd 为例）

要让 rsh 真正可用，远程主机必须启动 rsh 服务。在传统 Red Hat 系列发行版中，rsh 由超级守护进程 xinetd 托管，且默认不启动，配置步骤如下：

1. 使用 ntsysv 命令打开服务配置界面，在 rsh 选项前用空格键选中，确定退出；

2. 重启 xinetd 使配置生效：

   service xinetd restart
   

3. 若需允许 root 用户通过 rsh 登录，需编辑 /etc/pam.d/rsh，将 auth required /lib/security/pam_securetty.so 一行用 # 注释掉（只有注释掉该行才能用 root 登录）；

4. 在双方主机的 /etc/hosts 中添加对方的 IP 与主机名，并在双方对应账号的主目录下建立 .rhosts 文件、写入对方的 hostname，完成信任关系配置。

与 rsh 配套的 rcp 手册页 中给出了相同思路的完整配置过程：该文档明确指出 rcp 不提示输入口令，它通过 rsh 命令来执行拷贝，因此 rcp 与 rsh 共享同一套 .rhosts / hosts.equiv 信任体系。可以推断：rsh 服务端是否可用，直接决定了 rcp 能否免密复制文件。

典型使用场景

场景一：远程执行单条命令

rsh webserver1 date

远程主机 webserver1 上的 date 命令输出会直接显示在本地终端。

场景二：指定远程用户名执行

rsh -l karen webserver1 ls -l /home/karen

以 karen 的身份在远程主机上列出目录内容，输出回传本地。

场景三：脚本化批量操作

for host in web1 web2 web3; do
  rsh -n "$host" 'systemctl restart nginx && echo OK'
done

-n 选项保证脚本执行期间 rsh 不读取本地终端输入，避免交互阻塞。

场景四：调试连接问题

rsh -d webserver1 hostname

当认证或连接异常时，-d 输出的 Socket 层信息有助于定位问题发生在 TCP 连接阶段还是认证阶段。

rsh 在仓库其他命令中的底层角色

rsh 的价值不仅体现在自身，它还是多个经典远程工具的数据通道。从当前仓库的文档中可以找到多处印证：

• rcp 手册页 明确指出：rcp 通过 rsh 命令来执行文件拷贝，且不提示输入口令；
• rsync 手册页 中，-e, --rsh=command 选项可指定使用 rsh、ssh 等方式进行数据同步，并给出示例 rsync -av -e rsh /tmp/src/ user@host:/tmp/dest/；当源或目标路径含单个冒号分隔符时即自动启用远程 shell 模式；
• tar 手册页 中，--rsh-command=COMMAND 选项允许指定"使用远程 COMMAND 代替 rsh"，默认值为 /usr/bin/ssh，说明 tar 跨主机读写归档时同样依赖 rsh/ssh 作为传输通道。

由此可见，在现代 Linux 发行版中 rsh 大多已被 ssh 取代（如 rsync、tar 的默认远程 shell 均已切换为 ssh），但在理解老系统运维脚本、阅读历史文档时，rsh 的语法与信任模型依然是必须掌握的基础知识。

安全注意事项

使用 rsh 前必须清醒认识其安全缺陷：

1. 明文传输：rsh 协议不加密任何数据，用户名、命令与输出均可被网络嗅探截获；
2. 信任机制脆弱：基于 IP 与主机名的 .rhosts / hosts.equiv 信任极易被伪造，任何能冒充来源主机的攻击者都可免密执行任意命令；
3. 无会话管理：相比 ssh 的密钥认证、会话加密与端口转发能力，rsh 功能单一且无法审计。

因此，在开放网络环境与生产系统中，应优先使用 ssh 替代 rsh（对应 ssh 手册页），仅在内网隔离、遗留系统兼容等明确场景下保留 rsh。

小结

rsh 是理解 Linux 远程管理演进史的重要命令：它用极简的语法完成了"远程执行命令"这一核心诉求，语法形态沿用至今；但它基于明文的信任模型也直接催生了 ssh 的全面替代。掌握 rsh 的选项、参数与 .rhosts 认证配置，既能读懂遗留系统的运维脚本，也能更深刻地理解 ssh 在认证与加密层面解决了哪些实际问题。