Je dois exécuter un script shell (windows / Linux) sur une machine distante.
J'ai SSH configuré sur la machine A et B. Mon script est sur la machine A qui exécutera une partie de mon code sur une machine distante, la machine B.
Les ordinateurs locaux et distants peuvent être des systèmes Windows ou Unix.
Existe-t-il un moyen de faire cela en utilisant plink / ssh?
shell
ssh
sysadmin
remote-execution
alpha_989
la source
la source
Réponses:
Si la machine A est une boîte Windows, vous pouvez utiliser Plink (partie de PuTTY ) avec le paramètre -m, et il exécutera le script local sur le serveur distant.
Si la machine A est un système basé sur Unix, vous pouvez utiliser:
Vous ne devriez pas avoir à copier le script sur le serveur distant pour l'exécuter.
la source
-s
option? cette page de manuel me porte à croire qu'elle traitera les entrées standard une fois les options de traitement terminées, qu'elles-s
soient utilisées ou non.sudo
, exécutezssh root@MachineB 'echo "rootpass" | sudo -Sv && bash -s' < local_script.sh
.HISTCONTROL=ignoreboth or ignorespace
à le faire fonctionner)ssh root@MachineB ARG1="arg1" ARG2="arg2" 'bash -s' < local_script.sh
crédits vont entièrement à la réponse de @chubbsondubs ci-dessous.C'est une vieille question, et la réponse de Jason fonctionne bien, mais je voudrais ajouter ceci:
Cela peut également être utilisé avec su et les commandes qui nécessitent une entrée utilisateur. (notez l'
'
hérédoc échappé)Edit: Étant donné que cette réponse continue de recevoir des bits de trafic, j'ajouterais encore plus d'informations à cette merveilleuse utilisation de heredoc:
Vous pouvez imbriquer des commandes avec cette syntaxe, et c'est la seule façon dont l'imbrication semble fonctionner (d'une manière saine)
Vous pouvez réellement avoir une conversation avec certains services comme telnet, ftp, etc. Mais n'oubliez pas que heredoc envoie simplement le stdin sous forme de texte, il n'attend pas de réponse entre les lignes
Edit: je viens de découvrir que vous pouvez mettre en retrait l'intérieur avec des onglets si vous utilisez
<<-END
!(Je pense que cela devrait fonctionner)
Voir également http://tldp.org/LDP/abs/html/here-docs.html
la source
<<'ENDSSH'
), les chaînes ne seront pas développées, les variables ne seront pas évaluées. Vous pouvez également utiliser<<ENDSSH
ou<<"ENDSSH"
si vous souhaitez une extension.Expect
peut être utilisé lorsque vous avez besoin d'automatiser des commandes interactives comme FTP.Pseudo-terminal will not be allocated because stdin is not a terminal.
message. Il faut utiliser ssh avec des-t -t
paramètres pour éviter cela. Voir ce fil sur SON'oubliez pas non plus d'échapper les variables si vous souhaitez les récupérer sur l'hôte de destination.
Cela m'a rattrapé dans le passé.
Par exemple:
imprime / home / user2
tandis que
imprime / accueil / utilisateur
Un autre exemple:
imprime "bonjour" correctement.
la source
ssh user2@host 'bash -s' echo $HOME /home/user2 exit
for
boucles exécutées enssh
session, la variable de boucle ne doit pas être échappée.ssh user2@host2 'echo hello world' | awk '{ print $1 }'
exécuter localement le script Awk. Si la commande à distance produit une immense production, vous devez éviter de tout copier sur le serveur local, bien sûr. Soit dit en passant, les guillemets simples autour de la commande à distance évitent le besoin de s'échapper.Ceci est une extension de la réponse de YarekT pour combiner les commandes distantes en ligne avec le passage des variables ENV de la machine locale à l'hôte distant afin que vous puissiez paramétrer vos scripts du côté distant:
J'ai trouvé cela extrêmement utile en gardant le tout dans un script, donc c'est très lisible et maintenable.
Pourquoi cela fonctionne. ssh prend en charge la syntaxe suivante:
En bash, nous pouvons spécifier des variables d'environnement à définir avant d'exécuter une commande sur une seule ligne comme ceci:
Cela facilite la définition des variables avant d'exécuter une commande. Dans ce cas, l'écho est notre commande que nous exécutons. Tout avant l'écho définit les variables d'environnement.
Nous combinons donc ces deux fonctionnalités et la réponse de YarekT pour obtenir:
Dans ce cas, nous définissons ARG1 et ARG2 sur des valeurs locales. Envoi de tout après user @ host en tant que remote_command. Lorsque la machine distante exécute les commandes ARG1 et ARG2, les valeurs locales sont définies, grâce à l'évaluation en ligne de commande locale, qui définit les variables d'environnement sur le serveur distant, puis exécute la commande bash -s en utilisant ces variables. Voila.
la source
ssh user@host "ARG1=\"$ARG1\" ARG2=\"$ARG2\"" 'bash -s' <<'ENDSSH'...
-s
est de pouvoir appliquer des arguments à des scripts provenant de stdin. Je veux dire, vous pouvez aussi bien l'omettre si vous n'allez pas l'utiliser. Si vous l'utilisez, il n'y a aucune raison d'utiliser des variables d'environnement:ssh user@host 'bash -s value1 value2' <<< 'echo "$@"'
Cela vous demandera un mot de passe, sauf si vous avez copié la clé publique de votre utilisateur hostA dans le fichier authorized_keys sur le répertoire d'origine de l'utilisateur .ssh. Cela permettra une authentification sans mot de passe (si elle est acceptée comme méthode d'authentification dans la configuration du serveur ssh)
la source
J'ai commencé à utiliser Fabric pour des opérations plus sophistiquées. Fabric nécessite Python et quelques autres dépendances, mais uniquement sur la machine cliente. Le serveur doit uniquement être un serveur ssh. Je trouve que cet outil est beaucoup plus puissant que les scripts shell transmis à SSH et vaut bien la peine d'être configuré (en particulier si vous aimez la programmation en Python). Fabric gère l'exécution de scripts sur plusieurs hôtes (ou hôtes de certains rôles), facilite les opérations idempotentes (comme l'ajout d'une ligne à un script de configuration, mais pas s'il est déjà là), et permet la construction d'une logique plus complexe (comme le Python la langue peut fournir).
la source
Essayez de courir
ssh user@remote sh ./script.unx
.la source
la source
En supposant que vous vouliez le faire automatiquement à partir d'une machine "locale", sans vous connecter manuellement à la machine "distante", vous devriez rechercher une extension TCL connue sous le nom d'Expect, elle est conçue précisément pour ce type de situation. J'ai également fourni un lien vers un script pour se connecter / interagir via SSH.
https://www.nist.gov/services-resources/software/expect
http://bash.cyberciti.biz/security/expect-ssh-login-script/
la source
J'utilise celui-ci pour exécuter un script shell sur une machine distante (testé sur / bin / bash):
la source
fortement recommandé de source le fichier d'environnement (.bashrc / .bashprofile / .profile). avant d'exécuter quelque chose dans l'hôte distant car les variables d'environnement des hôtes cible et source peuvent être différées.
la source
si vous voulez exécuter une commande comme celle-ci
temp=`ls -a` echo $temp
dans ``, cela provoquera des erreurs.la commande ci-dessous résoudra ce problème
ssh user@host ''' temp=`ls -a` echo $temp '''
la source
La réponse ici ( https://stackoverflow.com/a/2732991/4752883 ) fonctionne très bien si vous essayez d'exécuter un script sur une machine Linux distante à l'aide de
plink
oussh
. Cela fonctionnera si le script a plusieurs ligneslinux
.** Cependant, si vous essayez d'exécuter un script de commandes situé sur une
linux/windows
machine locale et que votre machine distante l'estWindows
, et qu'il se compose de plusieurs lignes utilisant **plink root@MachineB -m local_script.bat
ne fonctionnera pas.
Seule la première ligne du script sera exécutée. Il s'agit probablement d'une limitation de
plink
.Solution 1:
Pour exécuter un script batch multiligne (surtout s'il est relativement simple, composé de quelques lignes):
Si votre script de commandes d'origine est le suivant
vous pouvez combiner les lignes en utilisant le séparateur "&&" comme suit dans votre
local_script.bat
fichier: https://stackoverflow.com/a/8055390/4752883 :Après cette modification, vous pouvez ensuite exécuter le script comme indiqué ici par @ JasonR.Coombs: https://stackoverflow.com/a/2732991/4752883 avec:
Solution 2:
Si votre script batch est relativement compliqué, il peut être préférable d'utiliser un script batch qui encapsule la commande plink ainsi que comme indiqué ici par @Martin https://stackoverflow.com/a/32196999/4752883 :
la source
Ce script bash fait ssh dans une machine distante cible, et exécute une commande sur la machine distante, n'oubliez pas d'installer expect avant de l'exécuter (sur mac
brew install expect
)la source
Vous pouvez utiliser runoverssh :
-s
exécute un script local à distanceIndicateurs utiles:
-g
utilisez un mot de passe global pour tous les hôtes (invite de mot de passe unique)-n
utilisez SSH au lieu de sshpass, utile pour l'authentification par clé publiquela source
Tout d'abord, copiez le script sur la machine B à l'aide de scp
Ensuite, lancez simplement le script
Cela fonctionnera si vous avez donné l'autorisation exécutable au script.
la source