Execution de script distant avec ssh

JujuLand · Le 02/11/2015, à 18:09

Bonjour,

J'aurai besoin de pouvoir exécuter un script distant, et que celui-ci aille à terme, même s'il y a déconnexion.
J'ai deux solutions trouvées sur le net, mais qui ne fonctionnent pas car la commande nécessite un sudo.

Le script à exécuter est très simple :

#!/bin/bash

sudo apt-get update
sudo apt-get -y dist-upgrade

Les commandes trouvées sont les suivantes:

gnome-terminal -x ssh -X -p <PortSSH> <User>@<ip> screen -dm <script>
ou
gnome-terminal -x ssh -X -p <PortSSH> <User>@<ip> nohup <script>

Le problème vient principalement du sudo.
Si je n'insère pas le sudo, j'ai des messages d'erreur pour la non présentation du mot de passe
Si je l'insère après le screen, je n'ai pas accès à l'écran pour pouvoir rentrer le mot de passe, et il ne fait rien
Si je l'insère avant le script, c'est pareil

C'est pareil, semble-t-il avec le nohup

Sachant que je ne veux pas autoriser la connexion en root, bien évidemment.
Le problème est-il soluble dans l'eau, ou devrais-je me passer de cette fonctionnalité ?

Merci de vos lumières.
A+

maxire · Le 02/11/2015, à 18:49

Salut,

Pour régler le problème de demande de mot de passe, désactiver la demande de mot de passe pour user et commande apt-get dans /etc/sudoers de machine <ip>

<user> ALL=NOPASSWD: /..../apt-get # ---> ligne à ajouter dans /etc/sudoers

Remplacer /.../ par le chemin vers apt-get

Et au lieu de screen ou nohup pourquoi pas quelque chose de ce genre

gnome-terminal -x ssh -X -p <PortSSH> <User>@<ip> <script> &

Le script est alors lancé en arrière-plan.

JujuLand · Le 02/11/2015, à 22:03

J'y avait pensé, mais à priori, si je connais ce script, et il ne concerne que apt-get, je ne connais pas pour le moment tous les scripts que je pourrais avoir à lancer, et de plus, çà me semble pas top de désactiver la demande de mot de passe pour le user.
Mais bon, c'est peut-être ce que je ferai ...
Pour le commande que tu me proposes, j'ai l'impression que si elle sera bien en arrière-plan, je me demande si elle se poursuivrai si j'ai la connexion qui tombe ...

En fait, sur une connexion classique en ssh, j'ai déjà l'habitude de lancer ce script, mais j'ai eu deux fois le cas où un plein téléchargement, je perde la connexion avec le distant (toujours le même), je ne sais pas s'il passe en hibernation ou si ma connexion tombe, mais c'est un peu chiant pendant un dist-upgrade, je n'aimerais pas que çà coince ensuite en recommençant.

Bon, j'essaye ta solution ...

Merci
A+

JujuLand · Le 02/11/2015, à 23:58

Bon, j'ai fait divers tests:

nohup script et script & donnent le même résultat, et, si on coupe la connexion, le père passe du process de la connexion ssh à 1
Le script continue donc.
screen -dm script fait de même, mais en plus, il n'y a pas besoin de fermer le terminal, dès envoi de la commancde sur le distant, la connexion est fermée, ce que je cherchais aussi.

Restait le problème du sudo.
Je pense avoir trouvé la parade:
J'ai créé le script (coté serveur, évidemment) mysudo :

#!/bin/bash

sudo ls xljksfjio 2>/dev/null     # commande bidon qui ne me sert qu'à demander le mot de passe 
screen -dm "$1"

script auquel je passe le nom de mon script nécessitant d'être lancé en sudo. Pour plus de sureté, au cas où, j'ai préféré entourer ma commande entre double-quotes.

ce qui donne ceci pour la commande lancée en ssh :

cmd=gnome-terminal -x ssh -X -p <PortSSH> <User>@<ip> "mysudo <script>"

Pour vérifier que coté serveur tout est exécuté comme je le veux, j'ai créé un petit script qui vérifie çà et que je lance avec la commande que je veux exécuter in-fine :

#!/bin/bash

. colors
while true
do
   ps -aef|grep "$1"|grep -v "grep"|grep -v "test"
   sleep 2
   echo -en "$gRed"
   date
   echo -en "$noColor"
done

Comme retour, j'ai çà :

alain@aupeix-GX723:~$ ./test misajour
lundi 2 novembre 2015, 22:30:34 (UTC+0100)
lundi 2 novembre 2015, 22:30:36 (UTC+0100)
lundi 2 novembre 2015, 22:30:38 (UTC+0100)
lundi 2 novembre 2015, 22:30:40 (UTC+0100)
alain    17429     1  0 22:30 ?        00:00:00 SCREEN -dm misajour
lundi 2 novembre 2015, 22:30:42 (UTC+0100)
alain    17429     1  0 22:30 ?        00:00:00 SCREEN -dm misajour
lundi 2 novembre 2015, 22:30:44 (UTC+0100)
alain    17429     1  0 22:30 ?        00:00:00 SCREEN -dm misajour
...
lundi 2 novembre 2015, 22:35:22 (UTC+0100)
lundi 2 novembre 2015, 22:35:24 (UTC+0100)
lundi 2 novembre 2015, 22:35:26 (UTC+0100)

Bien sûr, je ne lance mysudo qu'en cas de besoin ...

Pour info, mon script misajour est le suivant :

#!/bin/bash

. colors
sudo apt-get update
echo " "
echo -e "$gCya apt-get dist-upgrade =>$noColor"
echo " "
sudo apt-get -y dist-upgrade
if [ "x$1" != "x" ]; then
   echo " "
   echo -e "$gCya Appuyez sur une touche pour fermer la fenêtre ...$noColor"
   read
fi

Pour un test complet, je vais renvoyer les sorties de apt-get update et apt-get dist-upgrade vers un fichier pour voir si tout est bien ok pour la commande que je veux en fin de compte lancer (ici misajour).
Je pense que c'est la cas, mais je suis comme Saint-Thomas ...

Je pense aussi qu'il est impératif que le script n'attendent aucune entrée clavier pour éviter d'avoir des process qui ne se terminent pas. C'est la raison de l'insertion d'un test en fin de misajour (car il sert aussi en mode interactif).

A+

Dernière modification par JujuLand (Le 03/11/2015, à 09:32)

JujuLand · Le 03/11/2015, à 13:54

Les tests que je viens de faire ne sont pas concluants:

- je ne vois pas arriver de demande de mot de passe
- mon test affiche çà

mardi 3 novembre 2015, 11:12:57 (UTC+0100)
christi+  5177     1  0 10:33 ?        00:00:00 SCREEN -dm misajour

- pas de log, donc pas d"exécution
- je vois çà :

christian@felicite-X751LN:~$ screen -wipe
There is a screen on:
	5177.misajour	(03/11/2015 10:33:45)	(Detached)
1 Socket in /var/run/screen/S-christian.

Un autre test a été de faire un ps pour voir les tty utilisés sur le serveur, et surprise:

root       954     1  0 10:04 tty4     00:00:00 /sbin/getty -8 38400 tty4
root       958     1  0 10:04 tty5     00:00:00 /sbin/getty -8 38400 tty5
root       966     1  0 10:04 tty2     00:00:00 /sbin/getty -8 38400 tty2
root       969     1  0 10:04 tty3     00:00:00 /sbin/getty -8 38400 tty3
root       979     1  0 10:04 tty6     00:00:00 /sbin/getty -8 38400 tty6
root      1645     1  0 10:04 tty1     00:00:00 /sbin/getty -8 38400 tty1
root      1861  1839  6 10:04 tty7     00:09:50 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
christi+ 29509 29495  0 12:41 ?        00:00:00 sshd: christian@notty
christi+ 29514 29510  0 12:41 ?        00:00:00 grep tty
sudo: pas de tty présent et pas de programme askpass spécifié

Il semblerait que la connexionb ne soit dans ce cas pas rattachée à un tty, ce qui expliquerait la non demande de mot de passe.

J'ai donc consulté le man de ssh, et j'ai trouvé çà :

     -f      Requests ssh to go to background just before command execution.
             This is useful if ssh is going to ask for passwords or
             passphrases, but the user wants it in the background.  This
             implies -n.  The recommended way to start X11 programs at a
             remote site is with something like ssh -f host xterm.

             If the ExitOnForwardFailure configuration option is set to “yes”,
             then a client started with -f will wait for all remote port for‐
             wards to be successfully established before placing itself in the
             background.

J'ai ajouté cette option, mais pas re résultat probant ...

A+

cyberesprit · Le 03/11/2015, à 14:19

(message supprimé car inutile)

Dernière modification par cyberesprit (Le 03/11/2015, à 14:20)

JujuLand · Le 03/11/2015, à 14:20

Je tourne en rond.
J'ai ajouté apt-get dans sudoers, mais çà ne change rien
Si je laisse les sudo devant les commandes apt-get de mon script, il ne se passe rien.
Si je l'enlève juste sur la deuxième commande, j'ai çà qui semble tout expliquer ...

E: Impossible d'ouvrir le fichier verrou /var/lib/apt/lists/lock - open (13: Permission non accordée)
E: Impossible de verrouiller le répertoire /var/lib/apt/lists/
E: Impossible d'ouvrir le fichier verrou /var/lib/dpkg/lock - open (13: Permission non accordée)
E: Impossible de verrouiller le répertoire d'administration (/var/lib/dpkg/). Avez-vous les privilèges du superutilisateur ?
 
 apt-get upgrade =>
 
sudo: pas de tty présent et pas de programme askpass spécifié
 
 Appuyez sur une touche pour fermer la fenêtre ...

Lors de l'update, le système s'aperçoit que je ne lance pas en sudo
Lors du dist-upgrade, il s'aperçoit que je n'ai pas de tty affecté, et ne peut donc demander le mot de passe.

J'ai comme l'impression que c'est mission impossible ...

A+

JujuLand · Le 03/11/2015, à 14:23

Merci cyberesprit, j'ai eu le contenu de ton post sur mon mail, et comme tu l'as deviné, il semble que le screen ne résout rien, lorsqu'il y a une demande de mot de passe (sudo).

Si tu regardes le dernier message que j'ai posté, tu en verras probablement la raison.
Cà semble mission impossible.

Merci
A+

bruno · Le 03/11/2015, à 14:30

Il faut que tu autorises une connexion en root par clé uniquement sur ton serveur, sinon tu n'y arriveras pas.

JujuLand · Le 03/11/2015, à 15:44

J'ai déjà choisi de ne permettre la connexion que par clé.
Apparemment, il ne devrait pas avoir de problème majeur à autoriser une connexion root.
Mais je ne suis pas trop chaud.

Si je ne m'abuse, çà se fait par :

PermitRootLogin yes
PasswordAuthentication no

Oui ?

Et la connexion se fera avec root@<ip>

Oui ?

Merci
A+

cyberesprit · Le 03/11/2015, à 15:48

Oui, mais dans ce cas il faut aussi indiqué ta clef publique dans le .ssh/authorized_keys de root.

Mais effectivement, il faudrait éviter de pouvoir se connecter directement via root ...

Dernière modification par cyberesprit (Le 03/11/2015, à 15:49)

JujuLand · Le 03/11/2015, à 15:55

Comment se font les prises de main sur les serveurs ?
En root ou non ?
Le problème n'est-il pas le même ?

A+

cyberesprit · Le 03/11/2015, à 15:58

Les prises en mains se font en root sur un réseau local fermé, sinon généralement on passe par un utilisateur sans pouvoir et se connecte en root via su.
Personnellement, je n'ai jamais eu à faire un script pour ça, donc je n'ai pas d'expérience à ce sujet. Ça me tente bien d'essayer tient.

JujuLand · Le 03/11/2015, à 16:04

Aurtre chose, j'ai eu de nouveau le plantage de la connexion, cette fois en lançant un dist-upgrade, et en essayant de le stopper par Ctrl-C.
Après, impossible de me reconnecter en ssh
J'ai donc appelé mon copain, et lui ai demandé de relancer le serveur ssh.
Et j'ai pu me reconnecter.
Donc, ce n'était pas en tombant en hibernation comme je le supposais précédemment, mais à cause du ssh qui se plantait.

Ce qui est curieux, c'est que je n'ai eu le problème que sur cet ordi ...

A+

Dernière modification par JujuLand (Le 03/11/2015, à 16:04)

cyberesprit · Le 03/11/2015, à 16:17

Ce n'est pas forcément un plantage ssh, mais il suffit d'un genre de déconnexion ou qu'un logiciel comme fail2ban te bloque en cours de route, et il faut attendre un (long) moment avant que le connexion ssh entre le client et le serveur reprenne si c'est possible (pas avec fail2ban à moins de l'arrêter ou le relancer).

Enfin c'est de mon expérience (et rien de pire qu'un partage ssh monté sur un client avec sshfs, qui se met à ne plus communiquer avec le serveur pour que tout ton système soit inutilisable jusqu'à ce que ça reprenne ... heureusement c'est rare, ça le fait aussi avec nfs).

Après, je me trompe peut-être.

JujuLand · Le 03/11/2015, à 16:24

Je n'utilise pas fail2ban dont j'ai entendu parlé, mais que je n'ai jamais essayé.
Je n'ai pas eu la patience d'attendre, et les fois où çà m'était arrivé, je n'avais pas donné suite , et j'avais attendu que le copain se reconnecte le lendemain ... hormis cette fois, évidemment, mais çà m'a permis de cibler ssh tout de même.

Dans le logiciel de maintenance à distance que je suis en train de mettre en place, il y a bien sur un accès possible en sshfs, mais je ne compte pas l'utiliser au travers d'internet tant que je suis en 512 Ko.

Fin 2016, on nous promet la fibre, alors, çà ira mieux ... et on verra à ce moment.

A+

bruno · Le 03/11/2015, à 16:57

Non, pour n'autoriser la connexion de root que par clé c'est :

PermitRootLogin without-password

JujuLand · Le 03/11/2015, à 17:03

Ah, ok

Merci
A+

maxire · Le 03/11/2015, à 18:08

Jujuland a écrit :

J'ai ajouté apt-get dans sudoers, mais çà ne change rien

Comment?
As-tu bien inséré ceci dans /etc/sudoers?

<user> ALL=NOPASSWD: /usr/bin/apt-get

JujuLand · Le 03/11/2015, à 20:12

Oui, enfin çà change un peu, mais çà ne passe pas.

Si je met le sudo, çà échoue comme précédemment
Si je ne le mets pas, çà me donne des messages d'erreur concernant la verrou qu'il ne peut pas créer (quelque chose comme çà), et ensuite deux ou trois erreurs qui en découle ...

A+

Dernière modification par JujuLand (Le 03/11/2015, à 20:13)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/11/2015, à 18:09

Execution de script distant avec ssh

#2 Le 02/11/2015, à 18:49

Re : Execution de script distant avec ssh

#3 Le 02/11/2015, à 22:03

Re : Execution de script distant avec ssh

#4 Le 02/11/2015, à 23:58

Re : Execution de script distant avec ssh

#5 Le 03/11/2015, à 13:54

Re : Execution de script distant avec ssh

#6 Le 03/11/2015, à 14:19

Re : Execution de script distant avec ssh

#7 Le 03/11/2015, à 14:20

Re : Execution de script distant avec ssh

#8 Le 03/11/2015, à 14:23

Re : Execution de script distant avec ssh

#9 Le 03/11/2015, à 14:30

Re : Execution de script distant avec ssh

#10 Le 03/11/2015, à 15:44

Re : Execution de script distant avec ssh

#11 Le 03/11/2015, à 15:48

Re : Execution de script distant avec ssh

#12 Le 03/11/2015, à 15:55

Re : Execution de script distant avec ssh

#13 Le 03/11/2015, à 15:58

Re : Execution de script distant avec ssh

#14 Le 03/11/2015, à 16:04

Re : Execution de script distant avec ssh

#15 Le 03/11/2015, à 16:17

Re : Execution de script distant avec ssh

#16 Le 03/11/2015, à 16:24

Re : Execution de script distant avec ssh

#17 Le 03/11/2015, à 16:57

Re : Execution de script distant avec ssh

#18 Le 03/11/2015, à 17:03

Re : Execution de script distant avec ssh

#19 Le 03/11/2015, à 18:08

Re : Execution de script distant avec ssh

#20 Le 03/11/2015, à 20:12

Re : Execution de script distant avec ssh

Pied de page des forums