rsh 是 Remote Shell 的缩写，它是一个允许用户在远程主机上执行命令的古老工具，在它出现之后，为了更安全，人们开发了 ssh (Secure Shell)，并逐渐取代了 rsh。
尽管 rsh 已经非常过时且不安全，但在一些特定的、封闭的内部网络环境中（某些集群系统或遗留的自动化脚本中），你仍然可能会遇到它，了解它的工作原理和配置方式仍然是有价值的。
rsh 是什么？
rsh 是一个客户端/服务器程序，它允许你在本地机器上执行远程机器上的命令，并将命令的输出返回到你的本地终端。
核心特点：
- 不安全：所有数据（包括用户名、密码、执行的命令和所有输出）都以明文形式在网络中传输，这极易被窃听（sniffing）和中间人攻击。
- 基于信任：
rsh的认证机制非常简单，它不使用密码，而是依赖于.rhosts文件和/etc/hosts.equiv文件来建立信任关系，如果信任关系建立，你就可以无需密码直接登录。 - 功能单一：主要用于执行单条命令，不像
ssh那样可以提供一个完整的交互式 shell 会话。
rsh 的工作原理（认证流程）
rsh 的认证流程是其最核心也最不安全的部分：
- 当你在本地机器上执行
rsh remote_host command时，rsh客户端会连接到远程主机的rshd(Remote Shell Daemon) 服务端口（通常是 514）。 rshd服务会检查两个文件来确定是否允许连接：/etc/hosts.equiv(系统级信任文件)~/.rhosts(用户级信任文件， 代表用户的主目录)
- 认证规则：
- 如果远程主机名（或 IP 地址）和本地用户名都出现在上述任一文件的一行中，并且该行以 开头（表示该用户不被允许），或者没有 （表示允许），则认证通过。
- 示例： 在远程主机
serverB的/etc/hosts.equiv文件中有一行serverA myuser，这意味着来自serverA机器的myuser用户可以无需密码登录serverB。 - 如果系统级文件
/etc/hosts.equiv中没有允许的条目，rshd会继续检查目标用户主目录下的~/.rhosts文件。 - 如果两个文件都没有找到允许的条目,或者找到了禁止的条目（以 开头），认证失败，连接被拒绝。
认证成功后，rshd 会在远程主机上启动一个 shell，并执行你指定的命令，然后将命令的标准输入、输出和错误流都重定向回本地客户端。
如何配置和使用 rsh
1 安装 rsh 客户端和服务器
在大多数现代 Linux 发行版中，rsh 默认没有安装，你需要分别安装客户端和服务器。
-
在 Debian/Ubuntu 上:
# 安装客户端 sudo apt-get install rsh-client # 安装服务器 sudo apt-get install rsh-server
-
在 CentOS/RHEL/Fedora 上:
（图片来源网络，侵删）# 安装客户端 (通常包含在 `rsh` 包中) sudo yum install rsh # 安装服务器 sudo yum install rsh-server
2 启动 rsh 服务
安装后,你需要启用并启动 rshd 服务。
-
对于使用
systemd的系统 (如 Ubuntu 16.04+, CentOS 7+):# 启动服务 sudo systemctl start rsh.socket # 设置开机自启 sudo systemctl enable rsh.socket # 检查服务状态 sudo systemctl status rsh.socket
3 配置信任关系（关键步骤）
假设你想要从本地主机 client.local 上的用户 alice 无密码登录到远程主机 server.local 上的用户 bob。
步骤 1：在远程主机 server.local 上操作
-
以
bob用户身份登录server.local。 -
在
bob的主目录下创建或编辑~/.rhosts文件。# 切换到 bob 用户 su - bob # 创建 .rhosts 文件 vi ~/.rhosts
-
在
~/.rhosts文件中添加一行，格式为本地主机名 本地用户名。# 内容如下 client.local alice- 重要提示：
.rhosts文件的权限必须非常严格，否则rshd会拒绝使用它进行认证，通常设置为600(仅所有者可读写)。chmod 600 ~/.rhosts
- 重要提示：
步骤 2：可选 - 配置系统级信任
如果你想允许 alice 从 client.local 登录到 server.local 上的所有用户，可以在 server.local 上编辑 /etc/hosts.equiv 文件。
# 使用 root 权限编辑 sudo vi /etc/hosts.equiv
添加一行：
client.local- 警告：系统级信任非常危险，它会降低整个系统的安全性。
4 使用 rsh 命令
配置完成后,你就可以在 client.local 上使用了。
# 语法: rsh [远程主机] [要执行的命令] # 示例1：执行一个简单命令 rsh server.local "ls -l /home/bob" # 示例2：执行一个交互式命令（注意，有些命令可能无法正常工作） rsh server.local "top -n 1" # 只显示 top 的第一屏 # 示例3：不指定命令，会启动一个远程 shell（体验很差） rsh server.local # 在远程 shell 中执行命令，退出后会回到本地
rsh vs. ssh：为什么应该永远使用 ssh
| 特性 | rsh (Remote Shell) |
ssh (Secure Shell) |
|---|---|---|
| 安全性 | 极不安全，所有数据明文传输 | 非常安全，所有数据加密传输 |
| 认证方式 | 基于 .rhosts / hosts.equiv，无密码 |
基于密码、公钥密钥、双因素认证等 |
| 端口 | 514 | 22 |
| 功能 | 主要执行单条命令 | 提供交互式 shell、文件传输、端口转发等 |
| 加密 | 无 | 强加密（如 AES, 3DES） |
| 现代性 | 过时、废弃 | 行业标准、广泛使用 |
| 配置文件 | .rhosts, /etc/hosts.equiv |
~/.ssh/config, /etc/ssh/ssh_config |
除非你被迫维护一个非常古老的系统，否则绝对不要使用 rsh，它是一个巨大的安全漏洞，所有使用 rsh 的场景都应该被 ssh 替代。
安全警告和最佳实践
- 绝对不要在互联网上使用
rsh：任何在公网上使用rsh的行为都等同于将你的系统密码和操作内容直接广播给任何人。 - 最小化信任范围：如果必须使用
rsh，只在绝对必要的情况下设置信任关系，并且只授予最小的权限，避免使用系统级的/etc/hosts.equiv。 - 检查文件权限：始终确保
.rhosts文件的权限是600，如果权限过于宽松（如644），rshd会忽略该文件。 - 监控日志：
rsh的连接尝试和成功/失败记录通常在/var/log/auth.log(Debian/Ubuntu) 或/var/log/secure(CentOS/RHEL) 中，监控这些日志可以帮助你发现未授权的访问尝试。 - 迁移到
ssh：最好的实践是彻底停止使用rsh，对于脚本，可以将rsh替换为ssh并使用 SSH 密钥对进行无密码登录，这既安全又方便。rsh server.local "command"->ssh user@server.local "command"
rsh 是一个历史产物，了解它有助于理解网络工具的演进，但在实际应用中，它应该被完全遗弃。
