Autorisations SSH et répertoire de base

53

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 utiliser ssh dans un compte de classe particulier sans entrer mon mot de passe, alors 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.

Le problème était que les autorisations étaient définies sur mon propre répertoire personnel. L'authentification sans mot de passe ne fonctionnait pas lorsque les autorisations de mon répertoire personnel étaient définies sur 770 (indépendamment des autorisations définies pour .ssh /), mais fonctionnaient avec des autorisations définies sur 755 ou 700.

Quelqu'un sait pourquoi SSH fait cela? Est-ce parce que les autorisations du répertoire personnel sont trop permissives? Pourquoi SSH refuse-t-il de s'authentifier avec les clés publique / privée lorsque le répertoire de base est défini comme plus permissif que 700?

ssh permissions action_potato
la source
1
A confirmé les réponses ci-dessous; le problème était que les autorisations de groupe sur le dossier de base n'étaient pas définies correctement (le message d'erreur de auth.log était: 'Authentification refusée: mode de propriété ou mode de répertoire / home / <utilisateur>'). Je vois que SSH a raison d’être sélectif en ce qui concerne les autorisations de répertoire principal.
action_potato
5
Saviez-vous que les wikis tag que nous avons ici? Si vous cliquez sur ssh puis sur learn more, vous verrez une liste de contrôle de ce qu'il faut faire lorsque SSH ne fonctionne pas, et elle mentionne les autorisations du répertoire de base.
Gilles 'SO- arrête d'être méchant'
Ah, désolé, je n'en savais rien! Merci pour l'information.
action_potato

Réponses:

54

C'est le comportement par défaut pour SSH. Il protège les clés de l' utilisateur en appliquant rwx------sur $HOME/.sshet en assurant que le propriétaire dispose des autorisations d' écriture à $HOME. Si un utilisateur autre que le propriétaire respectif dispose d'une autorisation d'écriture sur le $HOMErépertoire, il peut modifier les autorisations de manière malveillante $HOME/.ssh, en détournant éventuellement les clés de l'utilisateur known_hostsou quelque chose de similaire. En résumé, les autorisations suivantes sur $HOMEseront suffisantes pour que SSH fonctionne.

  • rwx------
  • rwxr-x---
  • rwxr-xr-x

SSH ne fonctionnera pas correctement et enverra des avertissements aux services de journalisation s’il existe une variante g+wou une variation de o+wl’ $HOMEannuaire. Toutefois, l'administrateur peut remplacer ce comportement en définissant StrictModes nole sshd_configfichier de configuration (ou un fichier similaire), bien qu'il soit clair que cela n'est pas recommandé .

George M
la source
1
Merci d'avoir mentionné StrictModes no. Dans ma configuration, une liste de contrôle d'accès est configurée sur le répertoire de base de l'utilisateur cible et sur tous ses descendants pour permettre les modifications apportées par un utilisateur semi-privilégié ( u:operator:rwx), et SSH n'aimait pas cela.
Intelfx
31

77x sur votre répertoire personnel signifie que tout le monde avec un GID correct peut déplacer votre répertoire .ssh et le remplacer par un autre. Les utilisateurs avec le bon GID ont des autorisations en écriture / exécution sur le répertoire de base et peuvent donc renommer / créer des fichiers / répertoires.

SSH est très difficile en ce qui concerne les autorisations, et cela devrait être le cas.

jippie
la source