与Perl的Expect.pm相比，rsh的优势是什么？

Question

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

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

两者之间有没有更好的方法？或者我应该使用完全不同的东西？

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

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

Answer 1

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

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

$ rsh -l username hostname

在这种情况下，不需要使用sudo。由于安全问题，现在绝对是研究ssh的时候了。语法是相同的，但ssh还允许稍微不同(我想说更好)的语法：

$ ssh username@hostname

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

Answer 2

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

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

Answer 3

我可以看到有多种方法可以做到这点：

• Expect over telnet、rsh或ssh
  • 的优点:单一连接，更少的逃逸问题
  • 缺点:不断变化的ssh中的脆弱性

​

• rsh/ssh每个命令单独握手
  • 的优点:更少的转义问题，在不断变化的environment
  • cons:中更可靠每个连接都需要时间进行身份验证，并且对于ssh，握手encryption

​

• rsh/ssh一次执行所有命令
  • 优点:单一连接(更少的开销)，比预期的更可靠
  • 缺点:维护上的脆弱性特别是当您获得大量语句时，转义问题更加普遍(在perl中进行转义，因此它仍然由rsh/ssh转义，因此它仍然由远程shell转义，以便它由sudo的远程shell正确处理

​

• rsh/ssh并运行脚本
  • 的优点:单连接，更可靠，更多maintainable
  • cons:找到一种方法将其转移到那里(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存在怎么办，等等)，但这就是我们的想法。