rsh 与 Perl 的 Expect.pm 相比有什么优势？答案

【问题标题】：What are the advantages of rsh versus Perl's Expect.pm?rsh 与 Perl 的 Expect.pm 相比有什么优势？
【发布时间】：2010-10-20 17:00:34
【问题描述】：

我有一个 Perl Expect.pm 脚本，它可以在多个远程 unix 主机上执行一些中等复杂的工作，例如打包应用程序、部署应用程序、检查日志等。

我的前任曾使用 rsh 编写过类似的脚本。

两者之间有更好的方法吗？还是我应该使用不同的东西？

我猜有人会提出 SSH；它基本上是 rsh 的替代品，对吧？不幸的是，我现在不能选择 SSH。

我应该补充的另一件事是，在登录后，我需要能够对特定用户进行 SUDO 以在远程主机上执行大部分操作。

【问题讨论】：

标签： perl unix expect remote-administration rsh

【解决方案1】：

我应该补充的另一件事是，在登录后，我需要能够对特定用户进行 SUDO 以在远程主机上执行大部分操作。

要解决这一点：使用rsh（或ssh），您可以指定要成为远程会话中的哪个用户：

$ rsh -l username hostname

在这种情况下无需使用sudo。由于安全问题，现在肯定是研究ssh 的时候了。语法是一样的，但ssh 也允许稍微不同（我会说更好）的语法：

$ ssh username@hostname

我发现expect 太挑剔了，但我的经验并不丰富。

【讨论】：

我相信这不适用于 expect "rsh -l username hostname" 因为我需要 sudo 进入的帐户不能用作登录帐户，或者我缺少什么？
好的。它可能行不通。但在那种情况下，我会说使用 sudo 可能是一个既定安全策略的结束。另一个需要考虑 ssh 的原因。

【解决方案2】：

他们做不同的事情。 Expect 是一种编写手动响应脚本的方法。 rsh -- 远程 shell，非受限 shell，不幸的名称冲突 -- 允许您在另一个系统上远程运行命令。

也就是说，使用 rsh 执行远程命令、运行 sudo 等的安全漏洞和其他缺点是巨大的。

【讨论】：

但是 expect 也允许远程登录到远程系统，这就是我目前使用它的方式，所以它似乎做了 rsh 所做的一切，等等。那么我为什么要使用 rsh？
拜托上帝，你不会的。可悲的是，telnet 引发了同样的问题——比如你的密码在你的 telnet 会话中以明文形式徘徊。
是的，我知道会出现安全问题，事实上我喜欢 perl 的原因之一是我可以简单地将初始登录行从 telnet 更改为 SSH它可用，那时我的脚本的其余部分应该继续按原样工作。所以基本上你现在看不出使用 rsh 的理由？
我会说，如果您有满意的工作脚本，我不会更改它们。有比期望或 rsh 更好的方法来做这种事情，但它们意味着重新设计你的流程。
关于“更好”的想法有什么建议吗？只是为了将来参考，你是对的，我不一定会改变现有的东西，但我想知道有什么替代品。

【解决方案3】：

我可以看到多种方法：

期望通过 telnet、rsh 或 ssh
- 优点：单一连接，更少的转义问题
- 缺点：在不断变化的环境中变得脆弱
rsh/ssh 每个命令单独
- 优点：逃逸问题更少，在不断变化的环境中更可靠
- 缺点：每个连接都需要时间进行身份验证，对于 ssh，握手加密
rsh/ssh 一次执行所有命令
- 优点：单一连接（开销更少），比预期更可靠
- 缺点：维护的脆弱性，尤其是当您在其中获得多个语句时，转义问题更为普遍（在 perl 中转义，因此它仍然被 rsh/ssh 转义，因此它仍然被远程 shell 转义，这样它被 sudo 的远程 shell 正确处理了吗？）
rsh/ssh 并运行脚本
- 优点：单一连接、更可靠、更易于维护
- 缺点：想办法把它拿到那里（rcp/scp 工作，NFS 工作，你需要确定最适合你的方法）。

考虑到所有因素，这是最轻微的问题，因为您可以简单地做类似的事情

 open my $fh, "|ssh user@host 'cat > /tmp/myscript'";
 print $fh $script;
 system qw(ssh user@host), "chmod u+x /tmp/myscript; /tmp/myscript; rm /tmp/myscript";

当然，您会添加一些错误处理（打开失败、如果 /tmp/myscript 存在怎么办等），但这就是想法。

【讨论】：

这是一个很好的答案，为此 +1。与期望与您最后强调的方法相比，唯一的缺点是它不会处理在目标主机上提示某些内容的事情，当然脚本可以将这些部分包含在本地期望脚本中，但这意味着每个目的地必须安装期望（或期望.pm）。我是否正确理解了您的方法？

【解决方案4】：

如果通过expect 在rsh 和telnet 之间进行选择，我会选择rsh。 Expect 脚本很脆弱。只需有人在远程机器上更改PS1 的值即可。使用rsh 还可以让您为最终进入 90 年代并开始使用 ssh 做好准备（因为您几乎可以将 rcp 更改为 scp 和 rsh 更改为 ssh 并且一切正常） .

【讨论】：

有趣，有点与我在上面对查理的 cmets 中得出的结论相反。那么 sudo 问题呢，我需要在登录后对不同的用户进行 sudo 并可能再次输入密码，rsh 可以这样做吗？
我认为您仍然对不同事物的作用感到困惑。 rsh 会做任何你可以在命令行上做的事情，所以是的，你可以通过网络发送一个 sudo。 expect 可以通过 telnet 和本地处理对话。我不是 perl 的忠实粉丝，所以我不会倾向于 rsh，但更好的是我会想到更强大的东西。不过，这需要更多地了解这项任务。
"rsh sudo command" 如果 sudo 设置正确，就可以正常工作。 sudo 的诀窍是将允许用户运行的那些命令列入白名单（例如“user machine nopasswd start_thing、stop_thing、get_thing_status”），而不是授予用户全权访问权限。
“如果 sudo 设置正确”。这是盒子上的根/管理员需要设置的东西，对吧？这些白名单命令不是帐户级别的设置，是吗？我问的原因是，在我们的环境中，让管理员改变任何东西都是一个漫长而艰巨的过程......
是的，设置 sudo 是系统管理员的任务。