我们的开发运营团队目前构建源代码并将该源代码部署到目标机 - 这是典型设置。目前我们使用 psexec 向远程主机发出命令（即关闭环境、传输新代码、重新启动环境等）。
我们是否最好使用 SSH 来处理这些事情？它会更可靠/更用户友好吗？有人能帮我了解每种方式的优缺点吗？
答案1
考虑到 Windows 并没有自带 SSH，因此您必须在您当前部署的所有机器上都设置它。
当然，您可以设置一个安装脚本，通过 psexec 使用 shell 脚本自动执行此操作:)
这确实取决于您的使用情况。
安全有多重要？
SSH 的设计初衷是替代 telnet。它像 telnet 一样为您提供远程计算机上的 shell，但所有数据都通过安全隧道发送，因此如果有人嗅探数据包，所有数据都将被加密。
总体而言，SSH 的用途更加广泛。您可以设置 TCP 转发，以便其他应用程序可以使用您的 SSH 隧道进行通信。VNC 就是一个例子。通常，远程帧缓冲区（您的屏幕数据）通过网络以未加密的形式发送。您可以通过 SSH 轻松连接到远程计算机，然后使用 SSH 隧道以安全的方式发送屏幕数据。
PSEXEC 是一款出色的工具，可以满足您上述描述。它无需额外设置（内置于 Windows 中）。
PSEXEC 使用 RPC（远程过程调用）进行通信。我相信，一旦建立了“通信通道”，数据就会被加密，尽管我并不完全确定所使用的方法（SSH 可以通过多种方式配置）。
但是，如果您需要提供任何用户凭据，那么它将通过网络发送in PLAIN TEXT。我相信这可能写在命令的输出中psexec /?。虽然我目前不在 Windows 框前进行验证。
看到这个关联对于选项，在示例部分之前有一个注释。
所以这又取决于你需要做什么。至于稳定性。我从来没有遇到过 PSEXEC 的稳定性问题。除非你在使用 PSEXEC 时遇到问题，否则我不会说稳定性是考虑使用 SSH 而不是 PSEXEC 的原因。
PSEXEC 不像 SSH 那样可配置。除非您遇到 PSEXEC 的限制，否则您可能需要考虑 SSH。如果您只是复制新代码并重新启动远程计算机，而不是通过 PSEXEC 传递凭据（即通过远程上的当前用户名运行命令），那么为什么不继续这样做呢？
事实上，如果您只需要复制和重新启动，为什么不使用一些cmd.exe命令（如copy/ xcopy/ shutdown（如果它在您的 LAN 上或者您有其他路由，如通过 VPN）而不是 PSEXEC？