Je viens de paramétrer la partie Samba sur mon Jeedom 4.0.61 afin que les backups soient également transféré sur mon NAS.
En allant dans la partie Sauvegarde (pour activer la partie Samba), je vois un message d’erreur concernant l’authentification pour Samba.
Après plusieurs essais, il s’avère que, sur ma machine du moins, si je mets un mot de passe complexe, cela ne passe pas.
Si je mets comme mot de passe : bonjourjeedom => C’est OK
Si je mets : dZ,7]GFF%r2.F#y&i3(g]5L$mzAfTMObT]j7Ug@cZ => NOK
Une raison valable à cela?
Sans compter que dès qu’il y a une erreur, le mot de passe est affiché en clair… Pas top du tout.
Essaye de faire fonctionner le transfert samba en dehors de jeedom avec un mot de passe complexe.
Si tu as la même erreur, adresse toi aux auteurs de l’outil (client samba) car ici personne ne pourra rien faire, si cela fonctionne alors un fix sera possible dans jeedom.
Le mot de passe en clair, c’est pareil en fait: c’est le client samba qui requière un mot de passe en clair; il y a déjà eu d’autres sujets à ce propos.
Cela fonctionne. Et encore heureux, vu que cela existe depuis… longtemps .
Je viens de faire l’essai. Alors, il y a une subtilité (sinon, ce serait trop facile). Il faut utiliser un fichier.
Test fait vite fait :
root@odroidc2:~# cat password.credo
username = test
password = dZ,7]GFF%r2.F#y&i3(g]5L$mzAfTMObT]j7Ug@cZ
domain = WORKGROUP
root@odroidc2:~# sudo smbclient //192.168.xxx.xxx/jeedom -A password.credo -I 192.168.xxx.xxx -c "cd /Backup;ls"
cd \Backup\: NT_STATUS_OBJECT_NAME_NOT_FOUND
. DA 0 Sun Sep 13 05:57:48 2020
.. DA 0 Wed Aug 26 12:08:25 2020
#recycle DAS 0 Sat Sep 12 15:22:56 2020
backup-Jeedom-4.0.61-2020-09-13-05h56.tar.gz A 139315465 Sun Sep 13 05:57:50 2020
5242880 blocks of size 1024. 5106828 blocks available
Concernant le mot de passe chiffré, c’est pareil. C’est possible. Mais en utilisant des fichiers en parallèle.
juste un commentaire sur ma tentative de mise en place de backup externe
il y a des reponses qui peuvent etre utile sur Backup samba sur PC, par exemple.
mais j’ai decouvert que si votre mot de passe SMB utilise certains caracteres, cela va empecher la connexion et généré aussi une erreur « NT_STATUS_LOGON_FAILURE »
un moyen de le tester, dans la console linux (en dehors de Jeedom): sudo smbclient //<serveur_nas>/<partage> -U <compte>%<mot de passe>
si votre mot de passe contient un @ ou un %, chez moi ça génére session setup failed: NT_STATUS_LOGON_FAILURE
petite precision tres con pour un gars pas specialiste de linux comme moi, en faisant cette commande sudo smbclient
meme si vous mettez un mot de passe dans la ligne de commande, le linux va vous demandez un mot de passe c’est pour le sudo…
le mot de passe peut etre long et quand même utiliser des caracteres speciaux « simples » mais pas de $ ou &
Encore une fois… Avec l’utilisation d’un fichier cela fonctionne. Voir mon exemple plus haut.
Bien entendu, si un jour c’est intégré, le mot de passe est à chiffrer et non à laisser en clair comme dans mon exemple.
Pour ce problème, c’est la manière dont utiliser l’outil qui devrait changer.
C’est comme un merlin (cousin de la hache), je peux l’utiliser pour fendre des bûches avec son côté aiguisé ou telle une masse côté nuque. Même outil, utilisation différente.
Oui, via la simple commande Samba, on peut se loguer avec un mot de passe simple… Mais de cette manière, l’utilisation du mot de passe complexe ne fonctionne pas. Il faut utiliser une autre méthode… Donc ce n’est pas l’outil le problème mais la méthode utilisée.
Et on encrypteterait le fichier avec quoi ?
Avec un clé en clair dans le code ?
Il n’y aura aucun moyen de sécuriser ce mot de passe sur le disque sans que la restauration du backup sur un autre jeedom ne fonctionne plus: on ne pourra plus lire le fichier.
Tout ce débat pour quelques caractères alors que d’autres caractères spéciaux passent.
Et encore @Tonic8 a trouvé qu’il y avait moyen de les encoder.
Tu peux aussi proposer un PR
Sinon on peu retourner l’exemple :
Jeedom a utilisé un merlin et te dit de ne fendre que du bois avec.
Mais toi tu veux absolument l’utiliser comme une masse et ça ne fonctionne pas.
Je n’ai pas regardé cette partie. Tu as peut-être raison. Je ne sais pas.
Mais… Actuellement, le mot de passe est déjà en clair dans la BDD, non? Vu qu’il est affiché en clair en cas d’erreur. A moins qu’il soit chiffré puis déchiffré…?
Ben, il suffirait de stocker la clef de déchiffrement de la même manière, non? Simple question… C’est un débat, pas une attaque. Peut-être que je suis à côté de la plaque.
As-tu essayé? Il me semble avoir déjà tenté mais je vais ré essayer avec un caractère puis un autre et j’indiquerais dans le post si cela passe ou pas. J’avais déjà vu le problème d’encodage en faisant des recherches.
Mais dans le cas où cela fonctionne, il serait peut-être judicieux de faire un test sur le mot de passe pour voir s’il y a des caractères qui ne fonctionnent vraiment pas et l’indiquer à l’utilisateur. Et si des caractères spéciaux peuvent être remplacés par autre chose, le faire automatiquement…
Et dans un premier, temps, l’indiquer à l’utilisateur dans un message ou même dans la doc peut-être?
C’est tout de même assez incroyable… Dès que l’on pointe le doigt sur quelque chose, on met de gros boucliers en répondant de proposer un PR.
Tu m’as demandé dans ta première réponse de faire fonctionner Samba en dehors de Jeedom.
Ce que j’ai fait. Simplement que cela ne te plait pas.
Tu m’as même demandé si j’avais lu ta réponse alors que visiblement, c’est toi qui ne lisait pas la mienne.
Cela devient vraiment navrant les discussions avec certaines personnes ici.
Il faudrait peut-être que certains descendent de leur piédestal…
Je fais part d’un souci. Bon, c’est vrai, un mot de passe sécurisé, ça sert à quoi? Quelle connerie de ma part… En entreprise, les DSI me riraient au nez si je voulais utiliser un mot de passe sécurisé bien entendu… Que suis-je bête…
Bref, tu as pris la peine de me répondre (merci) en pointant du doigt l’outil (qui a plus de 30 ans) et en me disant que si le problème vient de Jeedom, il y aura une correction.
J’ai pris du temps pour chercher (car je pensais que c’était communautaire ici)… Et j’ai trouvé une solution fonctionnelle… Mais visiblement cela ne plait pas car cela pointe le doigt vers Jeedom.
Alors je ne dis pas qu’une telle modification se fait en un claquement de doigt. Surtout que cela vient à se rajouter à de nombreux travaux. Mais de là à répondre ce que tu réponds (en gros l’outil doit s’adapter à Jeedom et non le contraire)… Autant ne rien répondre… Car le forum reste publique et au vu de certaines réponses…
Tu vois, si on m’avait simplement répondu qu’au vu de la charge de travail cela ne va pas être résolu court terme mais que l’on met ça dans la ToDo List, cela aurait été une réponse correcte.
Mais pensez plutôt à préciser qu’il ne faut surtout pas pointer du doigt des problèmes, ce sera moins prise de tête avec les membres .
Peut-être que pour une raison que j’ignore, cela n’est pas possible mais quand je lis ça :
Désolé si j’ai été un peu trop directe et que c’est passé pour une attaque (ou un bouclier).
Tu as fait fonctionner samba en dehors de jeedom mais par un moyen que jeedom n’utilise pas (le fichier); en ligne de commande cela ne fonctionne pas, dans jeedom ou en dehors et c’était ca mon point.
Et donc l’histoire du PR est sérieuse, en tout cas comme je vois les choses: jeedom est un code opensource, il y a d’autres contributeurs que Loic et il pourrait (devrait?) y en avoir plus!
Donc si tu arrives à mettre au point un système pour qu’au final ça soit mieux et bien il faut le faire; ce n’est pas pour placer un bouclier, pas du tout
Après si on revient sur la question du mot de passe et de l’encryption, c’est vraiment un problème récurent (et je ne parle pas de jeedom ici);
je vois tout le temps le même débat passer professionnellement: c’est en clair, on veut encrypter mais ou stocker la clé? ok en db… oui mais pas en clair parce que la db peut être volée (c’est pour ca qu’on ne mettait pas le mot de passe dedans), il faut aussi l’encrypter mais ou…
bref il n’y a pas de solution, c’est l’histoire de l’oeuf ou la poule.
La seule solution c’est d’avoir un hsm (ou équivalent) ce qu’il n’y a pas encore moyen (à ma connaissance) de déployer facilement dans une install type jeedom tout apportant réellement quelque chose de plus pour la sécu. (j’ai pas dit que ca ne sera jamais possible)
J’avoue également été un peu brute dans ma réponse.
Mon seul but était de soulever un « problème », rien de plus. Je souhaite que Jeedom évolue car c’est une solution que j’apprécie. Mon but n’est pas d’attaquer. Je voulais simplement lancer la discussion.
J’ai calmé mes ardeurs depuis . Désolé si j’étais un peu trop dans l’attaque.
[START BACKUP]
***************Start of Jeedom backup at 2021-03-09 09:16:19***************
Envoi l'évènement de début de sauvegarde...OK
Vérification des droits sur les fichiers...
OK
Vérification de la base de données...
OK
Sauvegarde la base de données...
OK
Persistance du cache :
OK
Création de l'archive...
OK
Nettoyage de l'ancienne sauvegarde...OK
Send backup Samba...
Delete backup too old : {"filename":"Ignoring","size":"parameter","datetime":"1970-01-01 01:00:00"}
[2021-03-09 09:17:47][ERROR] : Erreur sur sudo smbclient //192.168.1.20/Sauvegarde -U "Jeedom_salon%XXXX*" -I 192.168.1.20 -c "cd /Jeedom_Delta;del Ignoring" 2>&1 valeur retournée : 1. Détails : Unknown parameter encountered: "password level" Ignoring unknown parameter "password level" Unknown parameter encountered: "password level" Ignoring unknown parameter "password level" NT_STATUS_NO_SUCH_FILE listing \Jeedom_Delta\Ignoring
/!\ Erreur sur sudo smbclient //192.168.1.20/Sauvegarde -U "Jeedom_salon%XXXX" -I 192.168.1.20 -c "cd /Jeedom_Delta;del Ignoring" 2>&1 valeur retournée : 1. Détails : Unknown parameter encountered: "password level"
Ignoring unknown parameter "password level"
Unknown parameter encountered: "password level"
Ignoring unknown parameter "password level"
NT_STATUS_NO_SUCH_FILE listing \Jeedom_Delta\Ignoring /!\OK
Limitation de la taille des sauvegardes à 1000 Mo...
OK
Nom de la sauvegarde : /var/www/html/core/php/../../backup/backup-Jeedom_Delta-4.1.20-2021-03-09-09h16.tar.gz
Vérification des droits sur les fichiers...
OK
Envoi l'évènement de fin de sauvegarde...OK
Durée de la sauvegarde : 91s
***************Fin de la sauvegarde de Jeedom***************
[END BACKUP SUCCESS]
J’ai les mêmes paramètres sur les deux jeedom (ils sauvegardent chacun dans un répertoire séparé évidemment).
Un souci avec le samba de la DELTA ?..
Je ne sais pas pourquoi mais cela marchait bien à une période.
Si une soluce a été trouvée, je suis preneur…
Bien à vous.
.
.
. Désolé si j’étais un peu trop dans l’attaque.
