[systemd] Lancer une commande ssh au boot et au shutdown

Support Debian
,
Tags: #<Tag:0x00007f63f4ef68e8> #<Tag:0x00007f63f4ef6820>
#1

Bonjour,

Je cherche à éxecuter automatiquement une commande au boot et une autre au shutdown de mon pc.
Ces commandes sont deux commandes ssh :

au boot :
ssh -p 2222 pi@192.168.23.6 kodi &
au shutdown :
ssh -p 2222 pi@192.168.23.6 'pkill kodi && sudo chvt 1 && sudo chvt 7'

La première sert à lancer kodi sur mon rpi sous raspbian. La seconde quitte kodi (le coup des chvt évite un écran noir, bug connu visiblement).

Apparemment, la solution la plus propre serait de créer un ou deux services systemd, mais là je sèche, j’ai tenté ça mais erreur d’authentification ssh. Pourtant, l’authentification (par clefs) se fait correctement dans une console classique manuellement.

[Unit]
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ssh -p 2222 pi@192.168.23.6 kodi &
ExecStop=ssh -p 2222 pi@192.168.23.6 'pkill kodi && sudo chvt 1 && sudo chvt 7'
User=jul
Group=jul

[Install]
WantedBy=multi-user.target

Edit:
J’ajoute le message d’erreur :

kodi.service
   Loaded: loaded (/etc/systemd/system/kodi.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2019-02-01 10:48:05 CET; 12s ago
  Process: 3576 ExecStart=/usr/bin/ssh -p 2222 pi@192.168.23.6 kodi & (code=exited, status=255/EXCEPTION)
 Main PID: 3576 (code=exited, status=255/EXCEPTION)

févr. 01 10:48:05 Arch systemd[1]: Starting kodi.service...
févr. 01 10:48:05 Arch ssh[3576]: Permission denied, please try again.
févr. 01 10:48:05 Arch ssh[3576]: Permission denied, please try again.
févr. 01 10:48:05 Arch ssh[3576]: pi@192.168.23.6: Permission denied (publickey,password).
févr. 01 10:48:05 Arch systemd[1]: kodi.service: Main process exited, code=exited, status=255/EXCEPTION
févr. 01 10:48:05 Arch systemd[1]: kodi.service: Failed with result 'exit-code'.
févr. 01 10:48:05 Arch systemd[1]: Failed to start kodi.service.
#2

Ben déjà, ça peut être mieux en activant le service que tu as créé:
systemctl enable kodi.service

Tu n’aurais pas un truc genre fail2ban, qui a bloqué ton ssh à force de faire des tests ?
As tu testé tes commandes ssh de start stop en ligne de commande avant de les scripter ?
(je sais, c’est con, mais sait on jamais).

#3

Il me semblait qu’on avait pas besoin de faire un “enable”, un “start” ne suffit pas pour tester.

Si, je me suis autoban hier en testant, il m’a fallu une heure pour m’en rendre compte…

oui, elles fonctionnent.

#4

Je suppose donc que vous avez copié les clés publiques de l’utilisateur jul dans un fichier /home/pi/.ssh/authorized_keys de la machine 192.168.23.5
Je vous conseille d’installer keychain sur cette machine. Vous modifiez ensuite la configuration du compte pide la manière suivante

  • Copie des clés privées du compte jul@PC? vers le compte pi@192.xxx

  • Dans le .bashrc (compte pi), vous ajoutez quelque chose comme

# https://blog.g3rt.nl/upgrade-your-ssh-keys.html
eval `keychain --eval id_rsa id_rsa_legacy id_ed25519`

où vous adaptez la liste des clés présentes.
Vous vous reconnectez ensuite une fois au pi et vous constatez qu’il vous demande la phrase de passe associée a(ux) clé(s) privée(s). Cela correspond au lancement d’un processus ssh-agent sur le Pi pour les connexions qui viennent du PC.
Tant que vous n’avez pas redémarré le Pi vus pourrez vous reconnecter depuis un compte associé a(ux) clé(s) sans donner de mot de passe ni de phrase de passe, grâce à l’agent lancé par keychain.
Je pense que dans ces conditions votre unitsystemd devrait fonctionner.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#5

Bonjour,

Désolé, je ne viens pas donner un coup de main, j’essaye simplement de comprendre de quoi il s’agit… Si je comprends bien, tu lances et arrêtes kodi sur ton raspberry en fonction de l’état de démarrage d’un autre PC, c’est bien ça ?

Personnellement je serais parti du Raspberry avec une tâche qui s’exécute toutes les deux minutes :

Stocker le résultat d'un test de connectivité du second PC (ping ?)
Stocker l'état actuel de kodi (démarré ou non)

SI le second PC est allumé et que kodi est éteint, ALORS
	démarrer kodi
SINON
	arrêter kodi
FIN SI

Et finalement, à quoi bon arrêter kodi sur un appareil qui va de toute façon rester allumé ?

#6

C’est exactement ça. Le RPI est allumé en permanence, mais kodi ne doit être lancé que quand mon pc est allumé. En effet, ce deuxième PC fait office de serveur de médias (via samba) pour kodi.
Kodi plante et remplit les logs lorsqu’il est lancé et que le serveur est éteint (et oui j’éteins mon PC, je pense à notre planète).

PS : c’est extrêment fatiguant de lancer et quitter kodi manuellement :sunglasses:

Je pense que vous tenez la bonne piste, je viens de tester avec de nouvelles clefs sans passphrase et ça fonctionne… Du moins le ExecStart pas le ExecStop ; mais chaque problème en son temps.

oui

J’avoue ne pas avoir encore trop compris votre solution, mais je vais me pencher dessus… J’essaie de tester tout ça.

Merci

#7

J’utilise LibreElec au boulot pour les petits films qu’on affiche à l’accueil, je n’ai jamais rencontré ce problème. Enfin, en tout cas j’ai compris le but, je te souhaite de l’atteindre =]

#8

Certainement dû au fait que j’utilise une base de donnée mysql distante hébergée également sur le pc éteint…

J’apprécie le geste :wink:

#9

Mauvaise idée ces clés sans phrase de passe.

Depuis votre PC

id
ssh-add -l

si erreur, lancez un agent et chargez vos clés

ssh-agent bash
ssh-add

vérifiez la copie dans ~ pi/.ssh/authorizd_keys

ssh -v -p 2222 pi@192.168.23.6  id

Pour simplifier la syntaxe je vous conseille fortement de renseigner l’adresse IP du Rasberry dans /etc/hostset créer un fichier ~/.ssh/config contenant

Host lepi  # nom donné au Pi
   Port 2222
   User pi

Auquel cas vous pouvez lancer

ssh lepi uptime

Tout ceci, sans mot de passe ni phrase de passe.

Pour en revenir à votre problème initial de piloter un processus kodi sur une machine distante et de lier le démarrage et l’arrêt aux séquences login/logout, je pense que l’idée de passer par systemd est bonne mais j’utiliserais des scripts pour

ExecStart=/home/jul/start_kodid
ExecStop=/home/jul/stop_kodi

avec pour strt_kodi quelque chose comme

#!/bin/bash

keychain --list  ||  { eval $(keychain --eval id_rsa ..)| ; keychain --systemd }
ssh lepi  kodi

donné sans garantie :slight_smile:

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#10

Bonjour à tous :slight_smile:

@jul

J’ai également bien compris le but recherché.
Tout comme sk4hrr, je te souhaite de l’atteindre.
Bien qu’équipé différemment, je vais continuer d’expérimenter dans ce sens.

J’ai installé keychain sur mon Pi d’après http://www.qanuq.com/2017/10/09/installer-ssh-keychain/
Je voulais voir comment ça fonctionne :slight_smile:

Je trouve keychain intéressant, bien que…
ce soit extrêmement fatiguant de saisir mots de passe ou phrases de passe :sunglasses:
et qu’il y ait transfert de la clef privée sur le poste distant ; ce qui peut paraître invraisemblable…

Utiliser un agent SSH a une incidence sur la sécurité, voici ce qu’il faut savoir.

  • Ne copiez pas votre clé privée sur un serveur non administré par vous, si vous le faites, vous partagez votre clé avec l’administrateur, la passphrase protège normalement votre clé, mais si vous avez copié votre clé privée, c’est que vous l’avez sans doute utilisée, vous avez donc partagé votre passphrase avec l’administrateur, même si cette opération n’est pas simple à réaliser, on peut se demander si la clé privée est compromise, à partir de cet instant. Ne stockez vos clés privées que sur des machines dites de confiance, encore mieux, ne lancez vos sessions SSH que depuis votre ordinateur personnel.
  • N’utilisez l’agent SSH ou l’agent forwarding que sur des machines administrées par vous car ces deux méthodes créent des variables d’environnement SSH_AUTH_SOCK contenant une socket vers l’agent SSH, il suffit à l’administrateur de mettre le chemin vers cette socket dans la variable d’environnement SSH_AUTH_SOCK de sa propre session pour avoir accès à toutes vos machines, sans mot de passe.

Concernant ce dernier point, on pourra ajouter ceci dans notre fichier ~/.ssh/config
pour interdire l’agent forwarding.

Host * ForwardAgent no

Dans mon contexte “à la maison” et sans auto-hébergement je me facilite la vie au maximum ;
je ne me donne quasiment aucun mot de passe à saisir et je n’utilise pas de trousseau.
Ce sont probablement de mauvaises habitudes très ancrées.

Je vais garder keychain en place et je pourrais toujours créer une ou plusieurs phrase de passe si besoin.

#11

Bien sûr, mais je suppose qu’en disant

vous êtes l’administrateur des machines du réseau local et que donc vous êtes conscient des deux points que vous avez longuement soulevés.

Avouez que c’est contradictoire avec lce que vous avez dit sur la sécurité d’une part et avec votre réponse

Pour être clair, en voyant ce « oui » j’ai eu l’impression que j’avais à faire à quelqu’un qui avance pas à pas dans la compréhension et ne recommence à zéro sans avoir trouvé exactement ce qui coince.
Pour être sûr d’être compris, je vous ai suggéré entre autre de lancer des commandes du genre

ssh -v -v -p 22222  pi@raspberrypi id

depuis le compte habituel ( jul ) avec les clés existantes.
Ceci vous aurait permis de comprendre les éléments en jeu.

Mais je vois que

  • vous lancez les commandes depuis un compte rem

  • vous n’avez pas donné le retour de

ssh-add -l

  • vous avez créé de nouvelles clés (pourquoi ? avec ou sans phrase de passe)

  • vous avez créé sur raspberrypi un fichier .bash_profileau lieu de modifier un fichier existant .bashrc. Ce fichier be contient pas une ligne ‘#!’.

  • on ne connaît pas le contenu des fichiers
    /etc/hosts ~/.ssh/config ~/.ssh/authorized_keyssur les deux machines (précisez si non présents)

  • vous avez confondu l’opérateur || (chaînage d’une commande si le code retour de la première commande est en erreur ) avec l’opérateur | (pipe)

Bref, c’est tr-s difficile à suivre. Peut-être y-a-t’il des erreurs de copier/coller ou de recopie ?
Cela peut vous paraître des critiques exagérées mais d’expérience j’ai constaté que si on s’y prend méthodiquement, que si on prend son temps en procédant pas à pas et en vérifiant systématiquement chaque étape, on y arrive du premier coup et donc on gagne du temps.

Pourrait-on avoir les retours de

getent hosts n73sm
getent hosts raspberrypi
hostname  --fqdn

sur les deux machines.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Les ampoules aux mains sont plus honorables que les bagues. »
Proverbe estonien

#12

Bonjour @littlejohn75

J’ai l’impression que vous m’avez confondu avec @jul, l’initiateur de ce sujet.
Moi @r2mi je me suis contenté d’expérimenter keychain à ma façon,
en suivant une partie de vos propos (script strt_kodi).

Cordialement,
Rémi

#13

Oups effectivement il y a erreur sur la personne. En tant que sexagénaire atteint depuis plus de 10 ans de Choriorétinopathie séreuse centrale j’implore votre pardon :slight_smile:
Je suis obligé d’utiliser la fonction zoom intégrée à xfwm4 ce qui fait que n’apparaît à l’écran qu’une petite partie de ce qui est affiché sans le zoom.

Ce qui est tout à votre honneur. L’utilisation de keychain dans un script start_kodi était là pour prévenir l’oubli éventuel du chargement de clés ssh avant de lancer kodisur un système distant.

Toutes mes confuses

Attendons la réponse de jul.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010

#15

Bonjour,

Dsl pour le temps de réponse, obligations familiales…
J’avoue que vous m’avez un peu perdu… :joy:

Du coup, je ne sais plus trop quelles commandes ont été demandées… Je fais donc le point de mon côté :

  • J’ai créé une paire de clefs ssh (sans passphrase) pour tester mon service systemd. D’ailleurs si je comprends bien, l’utilité de keychain se trouve là et permet d’utiliser des clefs avec passphrase.

  • Mon fichier kodi.service :

[Unit]
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ssh -p 2222 pi@192.168.23.6 kodi &
ExecStop=ssh -p 2222 pi@192.168.23.6 'pkill kodi && sudo chvt 1 && sudo chvt 7'
User=jul
Group=jul

[Install]
WantedBy=multi-user.target

Avec

systemctl start kodi.service

kodi se lance.
Mais avec

systemctl stop kodi.service

kodi ne s’arrête pas.

Autre problème, avec un

systemctl enable kodi

et redémarrage, kodi ne démarre pas, le service indique comme erreur :

févr. 03 10:22:18 Arch systemd[1]: Starting kodi.service...
févr. 03 10:22:18 Arch ssh[600]: ssh: connect to host 192.168.23.6 port 2222: Network is unreachable

Voilà où j’en suis pour le moment, je me dis que j’affinerai avec keychain, une fois que mon service fonctionnera correctement avec des clefs sans passphrase.

Merci à tous les deux en tout cas

#16

Bonjour jul
Oui, il y a eu un quiproquo.

Oui, en ayant à la saisir qu’une fois au démarrage de la machine.
De plus, si tu charges dans keychain plusieurs clefs privées qui ont la même phrase de passe,
celle-ci n’est demandée qu’une fois ; c’est un avantage.
Autrement, chaque phrase de passe est demandée, pour charger chaque clef privée.
Les clefs privées sans phrases de passe sont chargées sans aucune demande de keychain.

Comme je n’ai que mon Pi qui a systemd et que je peux redémarrer sans souci,
je procède différemment : j’essaye de faire marcher un kodi.service
depuis le Pi pour ouvrir et fermer Kodi sur ma station qui elle est sans systemd et toujours allumée.

J’ai écrit deux scripts sur le Pi qui réalisent bien sur ma station l’ouverture de Kodi et son arrêt.
J’ai beaucoup de mal avec systemd. Je débute complètement avec pour l’écriture en fait.
Pour le moment mes scripts ne fonctionnent pas intégrés au kodi.service

#!/bin/bash
#/home/pi/start-kodi

/usr/bin/ssh rem@n73sm DISPLAY=:0.0 kodi &

et

#!/bin/bash
#/home/pi/stop-kodi

/usr/bin/ssh rem@n73sm pkill kodi

Je n’ai pas eu besoin d’utiliser la commande chvt ; pas d’écran noir à l’horizon.

Voilà où j’en suis.
C’est une “catastrophe” ce sytemd bon sang ! :wink:
Dire qu’il faut apprendre ce “truc”…

#17

Bien d’accord, quelle histoire pour lancer une commande au boot… Ça m’étonne qu’il n’y ait rien de plus “user-friendly” !!

Pareil…

#18

Bonsoir,

Après pas mal de tâtonnements, mon service kodi fonctionne en faisant ça :

  • installation et activation de NetworkManager.service en lieu et place de dhcpcd.service
  • activation du service NetworkManager-wait-online.service
  • Utilisation de ce fichier kodi.service :
[Unit]
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/home/jul/.cron/start_kodi.sh
ExecStop=/home/jul/.cron/stop_kodi.sh
User=jul
Group=jul

[Install]
WantedBy=multi-user.target

#!/bin/bash
#start_kodi.sh
ssh -p 2222 pi@192.168.23.6 kodi &
exit

#!/bin/bash
#stop_kodi.sh
ssh -p 2222 pi@192.168.23.6 'pkill kodi && sudo chvt 1 && sudo chvt 7'
exit

Je vais me pencher sur cette histoire de keychain maintenant…

1 J'aime
#19

Oui c’est génial ! Ça marche impeccable avec une authentification par clef sans phrase de passe :slight_smile:

Par contre, dès qu’il y a keychain et une clef avec une phrase de passe, ce n’est pas aussi bien ;
Dans mon contexte inversé, il y a quelques soucis :
Le pkill kodi du stop du kodi.service ne se fait pas toujours bien.
Et si le kodi.service est activé (enabled), son start échoue au boot car la clef avec phrase de passe n’est pas encore chargée dans keychain.

Je ne peux pas vraiment expérimenter plus, dans mon contexte inversé sans clavier ni écran sur le Pi.

Dire que des gens qui utilisent Keychain cherchent à ne plus avoir à saisir les phrases de passe et cherchent à les fixer en dur dans la config ssh :thinking:

Je ne vois plus vraiment l’intérêt alors… Pour ce que j’en dis…

C’est suivant le contexte et l’usage voulu ;
Keychain peut convenir ou pas.

Si j’avais ton besoin chez moi, c’est clair que je m’en passerai.

Merci pour l’exemple du service systemd ; pour étudier.

J’avais tout ça en place sans le savoir vraiment.
Depuis mon sujet Mettre à jour une Raspbian avec Jessie