# \[systemd\] Lancer une commande ssh au boot et au shutdown **URL:** \ **Category:** Support Debian\ **Tags:** shutdown, ssh\ **Created:** [Février 1, 2019, 7:22 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503 "2019-02-01T07:22:02Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 1, 2019, 7:22 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/1 "2019-02-01T07:22:02Z")
Bonjour, Je cherche à éxecuter automatiquement une commande au boot et une autre au shutdown de mon pc. Ces commandes sont deux commandes ssh : ```nohighlight 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. ```nohighlight [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 : ```nohighlight 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. ``` ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Février 1, 2019, 10:01 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/2 "2019-02-01T10:01:58Z")
> [@jul](#): > > kodi.service; disabled Ben déjà, ça peut être mieux en activant le service que tu as créé: **systemctl enable kodi.service** > [@jul](#): > > ssh[3576]: Permission denied, please try again. 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). ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 1, 2019, 10:05 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/3 "2019-02-01T10:05:34Z")
> [@mattotop](#): > > Ben déjà, ça peut être mieux en activant le service que tu as créé: Il me semblait qu’on avait pas besoin de faire un « enable », un « start » ne suffit pas pour tester. > [@mattotop](#): > > Tu n’aurais pas un truc genre fail2ban, qui a bloqué ton ssh à force de faire des tests ? Si, je me suis autoban hier en testant, il m’a fallu une heure pour m’en rendre compte… > [@mattotop](#): > > As tu testé tes commandes ssh de start stop en ligne de commande avant de les scripter ? oui, elles fonctionnent. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 1, 2019, 10:19 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/4 "2019-02-01T10:19:24Z")
> [@jul](#): > > erreur d’authentification ssh. Pourtant, l’authentification (par clefs) se fait correctement dans une console classique manuellement. 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 `pi`de la manière suivante - Copie des clés privées du compte jul@PC? vers le compte [pi@192.xxx](mailto:pi@192.xxx) - Dans le .bashrc (compte `pi`), vous ajoutez quelque chose comme ```auto # 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 `unit`systemd 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 ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Février 1, 2019, 12:18 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/5 "2019-02-01T12:18:13Z")
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 : ```auto 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é ? ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 1, 2019, 1:29 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/6 "2019-02-01T13:29:55Z")
> [@sk4hrr](#): > > 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 ? 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 🕶 > [@littlejohn75](#): > > 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 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. > [@littlejohn75](#): > > Je suppose donc que vous avez copié les clés publiques de l’utilisateur `jul` dans un fichier `/home/pi/.sgh/authorized_keys` de la machine 192.168.23.5 oui J’avoue ne pas avoir encore trop compris votre solution, mais je vais me pencher dessus… J’essaie de tester tout ça. Merci ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Février 1, 2019, 1:48 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/7 "2019-02-01T13:48:20Z")
> [@jul](#): > > 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). 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 =] ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 1, 2019, 2:23 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/8 "2019-02-01T14:23:50Z")
> [@sk4hrr](#): > > J’utilise LibreElec au boulot pour les petits films qu’on affiche à l’accueil, je n’ai jamais rencontré ce problème. Certainement dû au fait que j’utilise une base de donnée mysql distante hébergée également sur le pc éteint… > [@sk4hrr](#): > > Enfin, en tout cas j’ai compris le but, je te souhaite de l’atteindre =] J’apprécie le geste 😉 ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 1, 2019, 4:33 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/9 "2019-02-01T16:33:55Z")
> [@jul](#): > > je viens de tester avec de nouvelles clefs sans passphrase et ça fonctionne… Mauvaise idée ces clés sans phrase de passe. > [@jul](#): > > oui Depuis votre PC ```bash id ssh-add -l ``` si erreur, lancez un agent et chargez vos clés ```bash ssh-agent bash ssh-add ``` vérifiez la copie dans ~ pi/.ssh/authorizd\_keys ```bash 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/hosts`et créer un fichier `~/.ssh/config` contenant ```bash Host lepi # nom donné au Pi Port 2222 User pi ``` Auquel cas vous pouvez lancer ```bash 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 ```auto ExecStart=/home/jul/start_kodid ExecStop=/home/jul/stop_kodi ``` avec pour strt\_kodi quelque chose comme ```bash #!/bin/bash keychain --list || { eval $(keychain --eval id_rsa ..)| ; keychain --systemd } ssh lepi kodi ``` donné sans garantie 🙂 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) ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Février 2, 2019, 8:21 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/10 "2019-02-02T08:21:23Z")
Bonjour à tous 🙂 @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 [Installer SSH keychain pour éviter d’avoir à saisir ses passphrases - Qanuq](http://www.qanuq.com/2017/10/09/installer-ssh-keychain/) Je voulais voir comment ça fonctionne 🙂 Je trouve keychain intéressant, bien que… ce soit extrêmement fatiguant de saisir mots de passe ou phrases de passe 🕶 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. ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 2, 2019, 11:19 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/11 "2019-02-02T11:19:58Z")
> [@anon97446390](#): > > Utiliser un agent SSH a une incidence sur la sécurité Bien sûr, mais je suppose qu’en disant > [@anon97446390](#): > > Dans mon contexte “à la maison” 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. > [@anon97446390](#): > > je ne me donne quasiment aucun mot de passe à saisir et je n’utilise pas de trousseau. Avouez que c’est contradictoire avec lce que vous avez dit sur la sécurité d’une part et avec votre réponse > [@jul](#): > > ```bash > > 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 > > ``` > > oui 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 ```auto 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 ```bash 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_profile`au 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_keys`sur 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 ```bash 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 ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Février 2, 2019, 11:59 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/12 "2019-02-02T11:59:06Z")
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 ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Février 2, 2019, 4:14 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/13 "2019-02-02T16:14:51Z")
> [@anon97446390](#): > > J’ai l’impression que vous m’avez confondu avec @jul, l’initiateur de ce sujet. 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](https://fr.wikipedia.org/wiki/Chorior%C3%A9tinopathie_s%C3%A9reuse_centrale) j’implore votre pardon 🙂 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. > [@anon97446390](#): > > je me suis contenté d’expérimenter `keychain` à ma façon, > en suivant **une partie** de vos propos (script strt\_kodi). 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 `kodi`sur 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 ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 3, 2019, 9:21 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/15 "2019-02-03T09:21:34Z")
Bonjour, Dsl pour le temps de réponse, obligations familiales… J’avoue que vous m’avez un peu perdu… 😂 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_ : ```nohighlight [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 ```nohighlight systemctl start kodi.service ``` kodi se lance. Mais avec ```nohighlight systemctl stop kodi.service ``` kodi ne s’arrête pas. Autre problème, avec un ```nohighlight systemctl enable kodi ``` et redémarrage, kodi ne démarre pas, le service indique comme erreur : ```nohighlight 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 ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Février 3, 2019, 10:27 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/16 "2019-02-03T10:27:51Z")
> [@jul](#): > > Bonjour, > > J’avoue que vous m’avez un peu perdu… 😂 Bonjour jul Oui, il y a eu un quiproquo. > [@jul](#): > > D’ailleurs si je comprends bien, l’utilité de keychain se trouve là et permet d’utiliser des clefs avec passphrase. 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 ```plaintext #!/bin/bash #/home/pi/start-kodi /usr/bin/ssh rem@n73sm DISPLAY=:0.0 kodi & ``` et ```plaintext #!/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 ! 😉 Dire qu’il faut apprendre ce « truc »… ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 3, 2019, 11:50 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/17 "2019-02-03T11:50:42Z")
> [@anon97446390](#): > > C’est une “catastrophe” ce sytemd bon sang ! 😉 Bien d’accord, quelle histoire pour lancer une commande au boot… Ça m’étonne qu’il n’y ait rien de plus « user-friendly » !! > [@anon97446390](#): > > Je débute complètement avec pour l’écriture en fait. Pareil… ---
**Author:** ![jul](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jul/32/4088_2.png) [@jul](https://www.debian-fr.org/u/jul)\ **Post date:** [Février 3, 2019, 6:57 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/18 "2019-02-03T18:57:58Z")
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_ : ```nohighlight [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 ``` ```nohighlight #!/bin/bash #start_kodi.sh ssh -p 2222 pi@192.168.23.6 kodi & exit ``` ```nohighlight #!/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… ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Février 4, 2019, 12:25 UTC](https://www.debian-fr.org/t/systemd-lancer-une-commande-ssh-au-boot-et-au-shutdown/78503/19 "2019-02-04T00:25:15Z")
Oui c’est génial ! Ça marche impeccable avec une authentification par clef sans phrase de passe 🙂 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` 🤔 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. > [@jul](#): > > - installation et activation de _NetworkManager.service_ en lieu et place de _dhcpcd.service_ > - activation du service _NetworkManager-wait-online.service_ J’avais tout ça en place sans le savoir vraiment. Depuis mon sujet [Mettre à jour une Raspbian avec Jessie](https://www.debian-fr.org/t/mettre-a-jour-une-raspbian-avec-jessie/78443)