Via mon Terminal, je me suis donc connecté en SSH a jeedom, généré une clé que j’ai copié dans mon NAS synology.
Le résultat : depuis le terminal connecté en SSH à jeedom, quand je lance ssh 'admin@ip_du_nas'
J’accède à mon NAS synology sans avoir à rentrer mon mot de passe >> donc OK.
Par contre quand je lance la même commande depuis le plug in script dans jeedom, j’ai ce message d’erreur: Erreur sur sudo ssh admin@192.168.2.100 sudo /sbin/poweroff 2>&1 valeur retournée : 255. Détails : Host key verification failed.
Je viens de tester, mais j’obtiens un message d’erreur également : Warning: Identity file /path/to/ssh/privatekey not accessible: No such file or directory. Host key verification failed.
J’ai essayé avec authorized_keys >> même message d’erreur.
Merci.
il faut mettre le chemin réel de la clé privée.
où l’as tu enregistré sur jeedom?
par exemple pour ma part le chemin de la clé privée: /home/jeedom/.ssh/id_ed25519
c’est ce chemin que je mets en paramètre -i de la commande citée au dessus
A oui OK je vois ce que tu veux dire.
Je vais chercher quel est le nom exacte de ma clé dans ce dossier.
Logiquement, vu le tuto que j’ai suivi, ça devrait être id_rsa
Alors quand je me connecte en ssh à jeedom et que j’affiche le contenu de .ssh, j’obtiens : id_rsa id_rsa.pub known_hosts
J’ai donc essayé ta commande avec ces 3 noms sudo ssh admin@192.168.2.100 -i /home/jeedom/.ssh/id_rsa sudo /sbin/poweroff 2>&1
et j’obtiens toujours la même erreur: valeur retournée : 255. Détails : Host key verification failed.
Bizarre
Mais du coup je pense que je n’ai pas le même chemin de .ssh que toi.
Existe t il une commande pour afficher l’arborescence des dossiers en ssh ?
edit: Pourtant si. Quand je fais la commande pwd dans .ssh j’obtiens : /home/jeedom
La paire de clés publique/privée a été créée avec le compte jeedom qui est la seul à avoir les droit d’accès nécessaires au répertoire /home/jssdom/.ssh et c’est très bien comme ça.
Par contre, le logiciel jeedom tourne avec le compte www-data . il n’a donc pas accès à la clé privée du compte jeedom qui est propriété privée du compte jeedom.
Il faut donc que tu génères un couple de clés pour le compte www-data
c’est là ou je voulais en venir effectivement (mais je savais pas si un sudo ssh pouvait lire la clé du compte jeedom)
www-data n’a pas de home je ne connais pas les recommendations en terme de sécurité dans ce cas, lui créer un dossier avec les droits en chmod 600 je suppose
Merci à vous deux pour votre aide.
Je comprends mieux pourquoi ça ne marchait pas.
Comme je suis un débutant dans l’utilisation du ssh, j’ai donc cherché comment faire pour générer une nouvelle clé pour www-data.
J’ai réussi facilement à me placer en tant que www-data.
Mais à partir de la, j’ai un doute sur les prochaines étapes. Voila ce que je compte faire :
1- ssh-keygen -f /home/www-data/.ssh/id_rsa
(j’ai trouvé cette info sur un autre post qui expliquait que positionner une clef privée dans la racine d’un site est une très mauvaise pratique … du coup il faut lors de la génération de la clef préciser un autre emplacement / Par contre est ce que cette commande va créer automatiquement les dossiers home/www-data et .ssh ? Ou dois je les créer un à un avec la commande mkdir??
2- Appliquer les droits à la clé: chmod 600 /var/www/home/www-data/.ssh/id_rsa
3- Copier la clé dans le NAS: ssh-copy-id -i ~/.ssh/id_rsa.pub "admin@ip_du_nas"
Et donc logiquement la commande à exécuter dans le plug script serait: sudo ssh admin@192.168.2.100 -i /home/www-data/.ssh/id_rsa sudo /sbin/poweroff 2>&1
Pouvez vous me confirmez cette procédure svp ?
Merci
Bon j’ai fait simple.
J’ai créé un couple de clés pour le compte www-data.
J’ai transféré cette clé au NAS.
Comme avec le compte jeedom, depuis le terminal j’arrive à me connecter au NAS sans mdp avec le compte www-data.
Mais malheureusement, quand je teste la commande depuis le plug script, j’obtiens la même erreur qu’au début : Erreur sur sudo ssh admin@192.168.2.100 sudo /sbin/poweroff 2>&1 valeur retournée : 255. Détails : Host key verification failed.
J’ai créé ce chemin (conseil de ddelec24): sudo mkdir -p /srv/keys
Malheureusement, impossible de copier les clés existantes dedans >> Acces denied ou permission denied je ne me rappelle plus…
J’ai donc essayé de recréer de nouvelles clés dedans > permission denied également.
J’ai quand même tester cette commande sous jeedom (script), en l’adaptant à l’emplacement de mes clés existantes: ssh admin@192.168.2.100 -i /var/www/.ssh/id_rsa sudo /sbin/poweroff 2>&1
Et nouveau message d’erreur: Erreur sur ssh admin@192.168.2.100 -i /var/www/.ssh/id_rsa sudo /sbin/poweroff 2>&1 2>&1 valeur retournée : 1. Détails : sudo: no tty present and no askpass program specified
Tu peux lancer la commande suivante avec le compte jeedom sudo -u www-data ssh-keygen
Cette commande créera un répertoire .ssh (avec les clés) dans /var/www qui est le homedir du compte www-data.
Pour info:
Les comptes locaux sont définis dans le fichier /etc/passwd Chaque ligne est composées de plusieurs champs séparés par des : un de ces champs est le homedir.
La commande getent passwd www-datate permet de voir les infos du compte www-data.
Tu peux lancer la commande suivante avec le compte jeedom sudo -u www-data ssh-keygen
Cette commande créera un répertoire .ssh (avec les clés) dans /var/www qui est le homedir du compte www-data
Je veux bien mais ça va écraser mes clés existantes alors. Celle que j’ai créé directement sous le compte www-data. Du coup ça changera quelque chose ?
J’ai testé la commande getent passwd www-data et voila ce que j’obtiens:
C’est bon, j’ai réussi à éteindre mes 2 serveurs (Synology et Unraid) en SSH avec jeedom.
J’ai donc bien utilisé la commande donnée par ddelec24 : sudo ssh admin@ip_du_nas -i /home/jeedom/.ssh/id_rsa sudo /sbin/poweroff 2>&1
Et j’ai également créé une paire de clé pour le compte www.data que j’ai transféré au 2 NAS.
Ce qui est bizarre et ce que je ne comprends pas, c’est que dans la commande précédente on force à aller chercher la clé privée dans le compte jeedom, alors que c’est le compte www.data qu’on utilise.
Enfin, ça marche, c’est l’essentiel !
Sans l’option -i ..., ssh va chercher la clé dans le répertoire .ssh qui se trouce dans le homedir de l’utilisateur qui a lancé la commande. Mais dans ton cas, tu indiques à sshd’utiliser une autre clé que celle qu’il utiliserai pas défaut.
dans ton cas, sudo ssh indique que la commande doit être exécutée avec les droits root. C’est probablement pour ça que le fichier /home/jeedom/.ssh/ir_rsa peut être lu alors le compte www-data n’y a certainement pas accès. Si tu n’avais pas préciser l’option -i ..., ssh aurai recherché le fichier ir_rsa dans le homedir de root car c’est ce compte qui lance la commande ssh.
Le mieux serais probablement de lancer la commande ssh admin@ip_du_nas sudo /sbin/poweroff 2>&1 en ayant la clé privée dans le fichier /var/www/.ssh/id.rsa du serveur jeedom et la clé public dans le fichier ./ssh/authirized_keys dans le homedir de admin
Attention, cette configuration permet à n’importe quel script (voulu ou non) tournant dans jeedom de lancer n’importe qu’elle commande avec les droits rootsur ton NAS.
Apres avoir réussi à éteindre mon Nas à distance en ssh via jeedom, j’ai remarqué que la commande ne marchait plus, alors que je n’avais rien changé.
Voici le nouveau message d’erreur : Erreur exécution de la commande : Erreur sur ssh root@192.168.2.50 -i /var/www/.ssh/id_rsa sudo /sbin/poweroff 2>&1 2>&1 valeur retournée : 255. Détails : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0775 for '/var/www/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "/var/www/.ssh/id_rsa": bad permissions Permission denied, please try again.
J’ai donc changé les permissions de la clé avec chmod 700, mais la clé id_rsa change de permission toute seule et revient en 777.
J’ai essayé de le faire en root, ou avec le compte www-data, mais ça ne change rien… au bout d’un certain temps (nouvelle journée ?) la clé repasse en 777 et la commande d’extinction du NAS ne fonctionne donc plus.
Avez vous une idée de comment régler ce problème ?
Problème provoqué par Splunk qui met tous les droits à 777 après (ou avant?) les backups (il y a aussi un bouton pour le faire sur la page de config system).
Les droits sont forcés à 777 sans tenir compte du type de fichier ou répertoire. Les images deviennent donc, entre autres, des fichiers exécutables.
Je n’ai pas de Jeedom sous la main pour chercher les détails mais un event, dont je ne me souviens plus le nom, est émis en fin de backup. Il doit donc être possible d’utiliser cet event pour déclencher un scénario qui remmette les droits de .ssh et de son contenu d’aplomb.
