无法通过SSH向瞻博networking防火墙发送命令

我有一些我需要pipe理的Juniper SSG防火墙，我希望能够通过一些监控脚本向他们发送命令。我使用公钥configurationSSH访问，我可以自动login到防火墙。

当我交互地运行SSH时，一切工作正常：

$ssh <firewall IP> FIREWALL-> <command> <command output> FIREWALL-> exit Connection to <firewall IP> closed. $

但是当我尝试从命令行运行命令时，它不起作用：

 $ssh <firewall IP> <command> $

当然，在向远程Linux机器发送一个命令时，

 $ssh <linux box IP> <command> <command output> $

为什么发生这种情况？交互式运行SSH和指定命令在SSH命令行上运行有何区别？

更新：

它也适用于Cisco路由器。只有这些瞻博networking防火墙似乎performance得如此。

从SSH的debugging输出中，看起来连接已经正确build立，但Juniper框在发送命令时用EOF回复，而Linux框则用实际的命令输出回应：

Linux的：

 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending command: uptime debug2: channel 0: request exec confirm 0 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 16:44:44 up 25 days, 1:06, 3 users, load average: 0.08, 0.02, 0.01 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0

瞻博networking：

 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug1: Sending command: get system debug2: channel 0: request exec confirm 0 debug2: callback done debug2: channel 0: open confirm rwindow 2048 rmax 1024 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 1

指定要运行的命令时，SSH不分配伪TTY。尝试添加“-t”选项来覆盖这个。

在命令行上传递命令与在shell中input命令不同。在第一种情况下，shell需要parsing参数，而在后者需要从标准input中读取行。

如果它是一个愚蠢的（或者有限的话，如果你更愿意称之为）交互式shell，它可能不会被编码来支持两者（我已经在实践中看到了这种行为）。但是，由于shell显然支持键入的命令，如果您只是将所有命令发送到其标准input，您可能会有更好的运气。喜欢这个：

 echo command | ssh ...

就像有人评论，尝试添加-t，甚至-tt来强制它。这个解决方法似乎解决了类似的问题。

我有一个相关的问题，事实上，除了我从CLI工作，但不通过cron工作。