Il m'a fallu des heures pour résoudre ce problème SSH avec l'un de mes comptes de classe sur les serveurs de mon école.
Je ne pouvais pas accéder à un compte de classe particulier sans entrer mon mot de passe, tandis que l'authentification sans mot de passe fonctionnait avec mes autres comptes de classe. Le répertoire .ssh/ et tout son contenu avaient les mêmes autorisations correctes que les autres comptes de classe.
Il s'avère que le problème était les autorisations définies sur mon propre répertoire personnel. L'authentification sans mot de passe ne fonctionnait pas lorsque les autorisations sur mon répertoire HOME étaient définies sur 770 (indépendamment des autorisations définies pour .ssh/), mais cela fonctionnait avec des autorisations définies sur 755 ou 700.
Quelqu'un sait pourquoi SSH fait ça ? Est-ce parce que les permissions du répertoire personnel sont trop permissives ? Pourquoi SSH refuse-t-il de s'authentifier avec les clés publiques/privées lorsque le répertoire personnel est défini plus permissif que 700 ?
Réponse acceptée :
C'est le comportement par défaut pour SSH. Il protège les clés des utilisateurs en appliquant rwx------ sur $HOME/.ssh et s'assurer que seul le propriétaire dispose des autorisations d'écriture sur $HOME . Si un utilisateur autre que le propriétaire respectif dispose d'une autorisation d'écriture sur $HOME répertoire, ils pourraient malicieusement modifier les permissions sur $HOME/.ssh , détournant potentiellement les clés utilisateur, known_hosts , ou quelque chose de similaire. En résumé, les autorisations suivantes sur $HOME sera suffisant pour que SSH fonctionne.
rwx------rwxr-x---rwxr-xr-x
SSH ne fonctionnera pas correctement et enverra des avertissements aux installations de journalisation en cas de variation de g+w ou o+w existe sur le $HOME annuaire. Cependant, l'administrateur peut remplacer ce comportement en définissant StrictModes no dans le sshd_config (ou similaire) fichier de configuration, bien qu'il soit clair que ce n'est pas recommandé .