fragen stichworte

Befehle können nicht über SSH an Juniper-Firewalls gesendet werden

Ich habe einige Juniper-SSG-Firewalls, die ich verwalten muss, und ich möchte in der Lage sein, Befehle von einigen Überwachungsskripts an sie zu senden. Ich habe den SSH-Zugriff mit öffentlichen Schlüsseln konfiguriert und kann mich automatisch bei den Firewalls anmelden.

Wenn Sie SSH interaktiv ausführen, funktioniert alles einwandfrei:

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

Wenn ich jedoch versuche, den Befehl über die Befehlszeile auszuführen, funktioniert er nicht:

$ssh <firewall IP> <command>
$

Dies funktioniert natürlich gut, wenn Sie einen Befehl an eine entfernte Linux-Box senden:

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

Warum passiert das? Was ist der Unterschied zwischen der interaktiven Ausführung von SSH und der Angabe des Befehls, der auf der SSH-Befehlszeile ausgeführt werden soll?


Update:

Es funktioniert auch gut mit einem Cisco-Router. Nur diese Juniper-Firewalls scheinen sich so zu verhalten.

Anhand der Debug-Ausgabe von SSH sieht es so aus, als ob die Verbindung korrekt hergestellt wurde, aber die Juniper-Box antwortet beim Senden des Befehls mit einem EOF, während die Linux-Box stattdessen mit der tatsächlichen Befehlsausgabe antwortet:

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

Wacholder:

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

antworten

SSH weist keine Pseudo-TTY zu, wenn Sie einen auszuführenden Befehl angeben. Versuchen Sie, die Option "-t" hinzuzufügen, um dies zu überschreiben.

Das Übergeben des Befehls in der Befehlszeile ist nicht dasselbe wie das Eingeben von Befehlen in der Shell. Im ersten Fall muss die Shell die Argumente analysieren und im zweiten Fall muss sie die Zeilen der Standardeingabe lesen.

Wenn es sich um eine dumme (oder begrenzte, wenn Sie es vorziehen, interaktive Shell zu nennen) ist, kann es sein, dass sie nicht für beide Arten codiert wurde (ich habe dieses Verhalten in der Praxis gesehen). Da die Shell jedoch offensichtlich typisierte Befehle unterstützt, haben Sie wahrscheinlich mehr Glück, wenn Sie alle Befehle an die Standardeingabe senden. Wie folgt:

echo command | ssh ...

Dies funktioniert auf einem SRX240:

( echo 'sh conf|d s|n'; echo 'quit' ) | ssh root@192.168.1.1 "cli"

Dies kann noch weiter verbessert werden, indem Sie einen bash-here- doc verwenden, so dass Sie nur vollständige Anweisungen einfügen können, aber dieses Beispiel sollte Sie vorläufig ausreichend leiten.

Wie jemand kommentiert hat, versuchen Sie es mit -t, oder sogar -tt, um es zu erzwingen. Ein ähnliches Problem wurde angeblich mit dieser Problemumgehung behoben.

Ich habe ein ähnliches Problem mit diesem Problem, außer mir funktioniert es vom CLI, funktioniert aber nicht über cron.