ssh clé publique "Server refused our key"

[pitch78]

Bon un petit post pour essayer de comprendre.

Il y a peut-être déjà tout (désolé si c'est le cas) mais j'ai pas trouvé.

ce que je veux :

• me connecter en ssh, par clé publique et non pas par mot de passe. je le fais déjà sur un autre NAS (1511+) et sur plusieurs raspberry.

La situation :

• un nouveau NAS (1817+)
• mêmes clés publiques (puisque je me connecte depuis les mêmes machines)
• .ssh créé dans le ~/.ssh de l'utilisateur
• /etc/ssh/sshd_config configuré "correctement"
• ~/.ssh en 700
• ~/.ssh/authorized_keys en 600

Le problème :

• lorsque je tente de me connecté via ssh (linux, osx) il me demande le mot de passe
• lorsque je tente depuis avec putty (il est plus explicite) il me dit Server refused our key, puis demande un mot de passe

Ce que j'ai vu et fait pour que ça marche :

• les droits du répertoire ~ de l'utilisateur sont : drwxrwxrwx+
• ne connaissant pas cette notation j'ai fait un chmod 700
• ça a fonctionné

Ce qu'il faut faire pour revenir à cette situation :

• aller dans homes sur filestation
• clic droit / propriétés sur le home de l'utilisateur concerné
• Onglet permission
• cliquer sur options avancées / inclures les permissions héritées
• les droits de ~ repassent à drwxrwxrwx+ et l'accès est à nouveau refusé

Du coup je me doute bien que c'est un problème de droit, mais j'avoue ne pas vraiment comprendre ou s'applique la restriction / quelle en est l'origine

Mes questions :

• quelle est la restriction qui joue ici
• que signifie drwxrwxrwx+
• mon action est-elle "dangereuse" et si oui comment concilier une configuration sécurisée comme à l'origine et un accès ssh par clé publique.

D'avance merci pour vos lumières !

 

 

 

 

 

Modifié le 13 juillet 2017 par pitch78

[Fenrir]

Les homes "linux" sont dans /var/services/homes sur les syno, mais en pratique c'est un lien vers /volume1/homes.

Pour root c'est le chemin posix : /root/.ssh/authorized_keys

Le problème c'est que dans les partages, Synology ne respecte pas les droits POSIX et y ajoute des ACL, tu peux les voir avec :

ls -lae /volume1/homes/LOGIN/.ssh

Au final les ACL (le + à la fin de la ligne) contredisent partiellement les droits POSIX, ce que ton chmod a corrigé

Il y a 5 heures, pitch78 a dit :

 drwxrwxrwx+

• d : c'est un dossier (- si c'était un fichier)
• rwx : droits lecture (r), écriture (w) et exécution (x) pour le propriétaire
• rwx : droits lecture (r), écriture (w) et exécution (x) pour le groupe
• rwx : droits lecture (r), écriture (w) et exécution (x) pour le reste du monde
• + : il y a des ACL

nb : x sur un dossier ça veut dire "entrer dans le dossier", sur un fichier c'est pour le rendre exécutable

Le bon chmod pour un .ssh c'est : chmod u+rwX,g-rwx,o-rwx dossier (il y a un X en majuscule, c'est important)

Un peu de lecture : https://wiki.archlinux.org/index.php/File_permissions_and_attributes

nb : Sous GNU/Linux, pour installer une clef sur un serveur, il y a une commande qui fait tout proprement : ssh-copy-id

Et pour ta dernière question, ce que tu as fait n'est pas dangereux, c'est Synology qui a tord.

[pitch78]

un grand merci, surtout que depuis j'ai aussi eu des problèmes (du même type) avec downloadStation qui ne me permettait pas de créer le répertoire par défaut pour les downloads.

du coup, maintenant je sais de quoi il retourne et je vais pouvoir me renseigner et en savoir un peu plus, car je connaissais pas du tout les ACL,

juste les droits "posix"et encore pas le "X"