Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

SSH avec passphrase mais le serveur NAS demande le password

cybernet

Et voilà le résultat de :

ls -l /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys
-rw-rw-r--+ 1 paul users 404 déc.  29 22:34 /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys

bruno

Ce dernier résultat est en contradiction avec ce que tu disais en #1 :

Sur le NAS :
- j'ai bien vérifié que le rep .ssh avait un chmod 700 et le fichier authorized_keys un chmod 600

Et le message d'erreur dans auth.log indique bien un problème de droits sur ce fichier

sudo chmod 600 /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys

cybernet

Bonjour Bruno,

Petite précision, je n'ai pas répété l'opération chmod sur .ssh et authorized_keys après ma 4ème tentative. Ceci dit, cela ne change rien au problème puisque après l'avoir fait ce matin (le rep .ssh est par défaut en 700 lorsque le transfert de clé est effectué avec la commande ssh-copy-id...), le problème est toujours récurrent.

Bon, ben je crois que je vais faire mes backup en manuel, faute d'avoir pu automatiser la chose avec LuckyBackup :-(

http://img11.hostingpics.net/pics/533773Slection026.png

http://img11.hostingpics.net/pics/968861Slection025.png

bruno a écritCe dernier résultat est en contradiction avec ce que tu disais en #1 :
Sur le NAS :
- j'ai bien vérifié que le rep .ssh avait un chmod 700 et le fichier authorized_keys un chmod 600
Et le message d'erreur dans auth.log indique bien un problème de droits sur ce fichier
sudo chmod 600 /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys

Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images (Des hébergeurs comme Toile Libre ou TDCT'Pix le permettent, hostingpics aussi).

maxire

Salut,

-rw-rw-r--+ 1 paul users 404 déc.  29 22:34 /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys

+ ===» Une ACL (Access Control List)est utilisée comme l'indique le signe + accolé en fin de descriptif des autorisations d'accès, cela ne casserait-il pas la baraque par hasard?

Personnellement je reviendrais à une situation classique sans ACL juste pour voir.
Le fait de ne pas prendre le répertoire utilisateur habituel ne devrait pas avoir d'incidence sur SSH.

bruno

Pourtant l'erreur dans les logs est tout à fait explicite :

Authentication refused: bad ownership or modes for file /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys

Il faut donc vérifier l'hypothèse de maxire ci-dessus et aussi voir si le système de fichiers du disque monté sur /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/ est bien compatible avec des droits UNIX.

cybernet

Bonjour maxire,

Alors, au niveau de la gestion des droits d'accès j'ai désactivé l'acl pour ne conserver que les privilèges sur le partage du dossier de base et tous les sous-dossiers, redémarré le nas (au cas ou...) mais ça ne change rien, j'ai toujours une demande de password à la connexion...

maxire a écritSalut,
-rw-rw-r--+ 1 paul users 404 déc.  29 22:34 /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys
+ ===» Une ACL (Access Control List)est utilisée comme l'indique le signe + accolé en fin de descriptif des autorisations d'accès, cela ne casserait-il pas la baraque par hasard?

Personnellement je reviendrais à une situation classique sans ACL juste pour voir.
Le fait de ne pas prendre le répertoire utilisateur habituel ne devrait pas avoir d'incidence sur SSH.

cybernet

Concernant les droits unix, c'est le cas puisque OMV est basé sur débian et j'ai formaté mes 3 disques en ext4

http://img11.hostingpics.net/pics/984145Slection027.png

je pige vraiment que dalle à ce problème :-(

bruno a écritPourtant l'erreur dans les logs est tout à fait explicite :
Authentication refused: bad ownership or modes for file /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh/authorized_keys
Il faut donc vérifier l'hypothèse de maxire ci-dessus et aussi voir si le système de fichiers du disque monté sur /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/ est bien compatible avec des droits UNIX.

Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images (Des hébergeurs comme Toile Libre ou TDCT'Pix le permettent).

maxire

Euh, ce fameux fichier authorized_keys n'est-il pas supposé être en 600?
Là je vois du 664...

cybernet

Oui, c'est le cas lors du transfert de la clé publique vers le serveur avec la commande ssh-copy-id qui met bien en chmod 700 le rep .ssh mais en 664 le fichier authorized.keys
J'avais oublié de le repassé en chmod 600, mais c'est fait voir le message #23)

maxire a écritEuh, ce fameux fichier authorized_keys n'est-il pas supposé être en 600?
Là je vois du 664...

bruno

Oui c'est ce que je disais plus haut, et la doc de SSH dit bien que les droits devraient être 700 pour .ssh et 600 pour authorized_keys

Les droits sur une copie d'écran cela ne prouve rien…
Il faut, sur le serveur, avoir le retour de

ls -al /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh

qui indique dwrx------ pour le dossier .ssh et -rw------ pour authorized_keys

Si ce n'est pas le cas, toujours sur le serveur, ajuster les droits, redémarrer le service ssh et refaire une tentative de connexion.

cybernet

aaaaahhhhhhhh, ça fonctionnnnnnnnnnne !

Alors, suite au dernier message de Bruno voilà ce que j'obtiens à la commande :

$ ls -l /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh
total 4
-rw-------+ 1 paul users 404 déc.  29 22:34 authorized_keys

Le petit '+' me laisse à penser (même si ça je l'ai appris grâce à vous...) qu'il y a encore des droits ACL en vigueur, donc direction la console OMV du NAS pour réinitialiser les droits acl sur le dossier, puis :

$ ls -l /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh
total 4
-rw-rw-r-- 1 root users 404 déc.  29 22:34 authorized_keys

Je m'aperçois cependant que le propriétaire n'est plus paul mais root, ce qui va m’empêcher de modifier le chmod pour .ssh et authorized_keys et ne plus me donner accès au sous-dossier LuckyBackup et continue à me demander le password à la connexion.
Je retourne donc modifier le droit de propriétaire à paul pour le dossier partagé et ses sous-dossiers, repasse .ssh en chmod 700 et authorized_keys en chmod 600 puis j'obtiens :

$ ls -l /media/902a5d4e-04df-49d0-9543-ac75aeeff2fa/Paul/.ssh
total 4
-rw------- 1 paul users 404 déc.  29 22:34 authorized_keys

Tentative de connexion :

cybernet@cybernet-Aero ~ $ ssh paul@192.168.0.20
Linux nas-noressal 3.2.0-4-amd64 #1 SMP Debian 3.2.81-1 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 30 17:18:07 2016 from cybernet-aero.local

Miracle, ça fonctionne sans demande de password ni passphrase cette fois 😃

Je retourne donner les droits de propriétaire à root pour voir, fait un essai... non concluant... retour à l'état précédent.

Petit test de LuckyBackup sur mon dossier 'Documents' et le test est concluant puisque le backup s’exécute sans demande de password ni passphrase également.

Un Grand merci à vous 2 pour votre patience et vos connaissances qui seront venus à bout de mon problème ;-)

« Page précédente