Question Impossible d'envoyer des commandes via SSH aux pare-feu Juniper


Je dois gérer certains pare-feu Juniper SSG, et j'aimerais pouvoir leur envoyer des commandes à partir de certains scripts de surveillance. J'ai configuré l'accès SSH à l'aide de clés publiques et je peux me connecter automatiquement aux pare-feu.

Lorsque je lance SSH de manière interactive, tout fonctionne correctement:

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

Mais lorsque j'essaie d'exécuter la commande à partir de la ligne de commande, cela ne fonctionne pas:

$ssh <firewall IP> <command>
$

Ceci, bien sûr, fonctionne bien lorsque vous envoyez une commande à une machine Linux distante:

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

Pourquoi cela arrive-t-il? Quelle est la différence entre exécuter SSH de manière interactive et spécifier la commande à exécuter sur la ligne de commande SSH?


Mettre à jour:

Cela fonctionne également très bien avec un routeur de Cisco. Seuls ces pare-feu Juniper semblent se comporter de cette façon.

D'après la sortie de débogage de SSH, il semble que la connexion soit établie correctement, mais la boîte Juniper répond par un EOF lors de l'envoi de la commande, tandis que la boîte Linux répond par la sortie de la commande réelle:

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

Genévrier:

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

6
2018-03-08 14:53


origine


Je pense que vous supposez que le démon ssh de Juniper appellera un shell pour exécuter vos commandes. Étant donné que l'environnement est limité, cette hypothèse peut ne pas être valide. - cjc
Vous avez très probablement raison (cela ne fonctionne sûrement pas avec un shell de type Unix), mais je peux exécuter des commandes de manière interactive, alors pourquoi ne puis-je pas en faire autant à partir de la ligne de commande SSH? En quoi est-ce différent? - Massimo
Pouvez-vous poster la sortie de ssh -v <firewall_IP> <command>? Vous pouvez également le comparer avec le résultat de Linux Box. - Khaled
@ Massimo Je ne suis pas le shell limité lui-même est la question. Je pense que c'est plus le démon ssh sur le routeur. Rien ne garantit que vous exécutez l'équivalent d'un OpenSSH sshd; quel que soit le serveur SSH qui y est exécuté, il n’a probablement que la capacité de vous fournir l’équivalent d’un TTY, et non la capacité d’exécuter des commandes dans le shell. - cjc
Comment cela affecte-t-il le client SSH? Que fait réellement SSH lorsque vous spécifiez une commande à exécuter sur la ligne de commande? N’ouvre-t-il pas une connexion et n’exécute-t-il pas la commande comme vous le feriez de manière interactive? - Massimo


Réponses:


SSH n'alloue pas de pseudo-TTY lorsque vous spécifiez une commande à exécuter. Essayez d'ajouter l'option "-t" pour remplacer ceci.


1
2017-10-27 08:36





Passer la commande sur la ligne de commande n'est pas la même chose que taper des commandes dans le shell. Dans le premier cas, le shell doit analyser les arguments et dans le second, il doit lire les lignes depuis l'entrée standard.

S'il s'agit d'un shell interactif muet (ou limité, si vous préférez l'appeler), il se peut très bien qu'il n'ait pas été codé pour prendre en charge les deux (j'ai vu ce comportement en pratique). Cependant, comme le shell supporte évidemment les commandes tapées, vous auriez probablement plus de chance si vous n'envoyiez toutes les commandes que sur son entrée standard. Comme ça:

echo command | ssh ...

0
2017-10-27 10:08





Comme quelqu'un l'a commenté, essayez d'ajouter -t ou même -tt pour le forcer. Un problème similaire aurait été corrigé avec cette solution de contournement.

En fait, j'ai un problème lié à celui-ci, sauf que pour moi cela fonctionne à partir de la CLI, mais pas dans cron.


0
2018-05-24 22:56





cela fonctionne sur un SRX240:

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

Cela peut être encore amélioré en utilisant un bash heredoc afin que vous puissiez simplement y coller des déclarations complètes, mais cet exemple devrait vous guider suffisamment pour le moment.


0
2017-08-07 08:40