Autorisations sur clé privée dans le dossier .ssh?

381

J'ai modifié mes autorisations dans mon .sshdossier et maintenant, lorsque j'utilise un logiciel qui utilise ma clé privée, je dois taper mon mot de passe à chaque fois. Quelles doivent être mes autorisations sur mon id_rsafichier pour ne pas avoir à saisir un mot de passe chaque fois que j'utilise une application qui l'utilise?

Actuellement, mes autorisations sont définies sur:

-rw-------@ 1 Jody  staff   114 Nov  4 23:29 config
-rw-------  1 Jody  staff  1743 Oct 21  2009 id_rsa
-rw-------@ 1 Jody  staff   397 Oct 21  2009 id_rsa.pub 
-rw-------@ 1 Jody  staff  3855 Sep 13 22:35 known_hosts

— JakeGould
source

640

En règle générale, vous souhaitez que les autorisations soient:

.ssh annuaire: 700 (drwx------)
clé publique ( .pubfichier):644 (-rw-r--r--)
clé privée ( id_rsa):600 (-rw-------)
Enfin, votre répertoire personnel ne devrait pas être accessible en écriture par le groupe ou par d’autres (au plus 755 (drwxr-xr-x)).

Je suppose que vous voulez dire que vous devez entrer votre mot de passe système / utilisateur à chaque fois, et que vous n'y étiez pas obligé auparavant. La réponse de cdhowie suppose que vous définissez un mot de passe / une phrase secrète lors de la génération de vos clés. Si tel est le cas, vous devrez entrer votre mot de passe à chaque fois sauf si vous utilisez un agent ssh.

— Fabs
source

13

J'ai trouvé ailleurs que si vous utilisez le fichier authorised_keys, il devrait être chmod'd à 640, c'est-à-dire -rw-r -----.

— AnneTheAgile

5

Où puis-je trouver cette information dans les pages de manuel?

— Sonique

132

Je suis revenu à ce poste environ 30 fois maintenant. Je ne peux pas croire que je ne m'en souvienne pas.

— JREAM

7

Les seules choses importantes sont que rien dans .ssh ne peut être écrit par personne d’autre et que les clés secrètes ne sont lisibles par personne d’autre.

— Markus Kuhn

5

L'autorisation @Cerin execute sur un répertoire permet de répertorier les fichiers / répertoires enfants immédiats de ce répertoire. Les fichiers du dossier ne "héritent" pas du bit d'exécution de leur dossier parent.

— Thomas le

87

Je me débattais avec cela pour toujours et j'ai finalement compris ce dont on avait besoin. Remplacez $USERpartout par le nom d'utilisateur SSH auquel vous souhaitez vous connecter sur le serveur. Si vous essayez de vous connecter comme rootvous auriez besoin d'utiliser /root/.sshetc., au lieu de /home/root/.sshce qui est comme ça pour les utilisateurs non-root.

Le répertoire de base sur le serveur ne doit pas être accessible en écriture pour les autres: chmod go-w /home/$USER
Le dossier SSH sur le serveur nécessite 700 autorisations: chmod 700 /home/$USER/.ssh
Le fichier Authorized_keys nécessite 644 autorisations: chmod 644 /home/$USER/.ssh/authorized_keys
Assurez-vous que c'est le userpropriétaire des fichiers / dossiers et pas root: chown user:user authorized_keysetchown user:user /home/$USER/.ssh
Placez la clé publique générée (depuis ssh-keygen) dans le authorized_keysfichier de l'utilisateur sur le serveur.
Assurez-vous que le répertoire de base de l'utilisateur correspond à ce que vous attendez et qu'il contient le .sshdossier correct que vous avez modifié. Sinon, utilisez usermod -d /home/$USER $USERpour résoudre le problème
Enfin, redémarrez ssh: service ssh restart
Ensuite, assurez-vous que le client a les fichiers de clé publique et de clé privée dans le .sshdossier de l'utilisateur local et se connecte:ssh user@host.com

— Alex W
source

En ce qui concerne votre premier paragraphe, je suis capable de ssh avec des clés publiques / privées avec un utilisateur de ma boîte linux locale (par exemple abc), différent de celui du serveur distant (par exemple def@123.456.789). Je devais assurer que l'utilisateur local propriétaire des fichiers .ssh locaux (par exemple abc:abc, non root:abc) `

— Michael

1

Merci d'avoir mis toutes les étapes et les commandes pour les débutants, Alex. Votre réponse est l’une des réponses les plus utiles ici.

— Nav

6

+1 "Le fichier Authorized_keys nécessite 644 autorisations" <= c'était crucial!

— Le Quoc Viet

Si vous donnez le mode .ssh au répertoire 700 , il ne sert à rien de donner r-- au groupe et aux autres, car vous seul pouvez "passer par" .ssh alors (en supposant qu'il n'existe aucun lien physique pour ces fichiers). La même chose pour la réponse acceptée. 755 par défaut suffit.

— user3125367

400 pour les fichiers PEM suffisent dans mon expérience.

— À

37

Assurez-vous également que votre répertoire personnel n'est pas accessible en écriture aux autres utilisateurs.

chmod g-w,o-w ~

— Felipe Alvarez
source

8

FYI, cette commande suppose que vous êtes connecté en tant qu'utilisateur et non root

— Alex W

6

Les autorisations ne devraient avoir rien à voir avec cela. Votre clé privée est cryptée avec le mot de passe. Vous devez donc la saisir pour que la clé privée soit déchiffrée et utilisable.

Vous pourriez envisager d’exécuter un agent ssh, qui peut mettre en cache les clés déchiffrées et les fournir aux applications qui en ont besoin.

— cdhowie
source

Merci pour les informations supplémentaires sur l'agent ssh. On dirait qu'il en existe un dans Leopard, alors je pense que je vais le faire. Avoir un peu de difficulté avec ça mais je vais poser une autre question.

5

Ne sous-estimez pas les autorisations. Ils entrent certainement toujours en jeu.

— Alex W

@AlexW Ils entrent en jeu avec d'autres aspects de ssh, mais pas celui évoqué dans la question.

— Cdhowie

Si vous ne possédez pas de mot de passe sur les clés privées (à la différence de scripts distants automatisés), cela ne vous aidera pas. Les autorisations sont nécessaires ici.

— nerdoc

"Je dois taper mon mot de passe à chaque fois. Quelles doivent être mes autorisations sur mon fichier id_rsa pour ne pas avoir à saisir un mot de passe chaque fois que j'utilise une application qui l'utilise?"

— Craig Hicks

4

Felipe est correct - le répertoire contenant votre répertoire .ssh ne doit pas être accessible en écriture par groupe ou autre. C’est donc chmod go-w ~la prochaine chose logique à essayer si vous êtes toujours invité à entrer un mot de passe après l’exécution de ssh ssh-keygen -t rsa; cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys, en supposant que vous n’affectiez pas de phrase secrète à la commande ssh-keygen et que votre répertoire .ssh se trouve dans votre répertoire personnel.

— Mikentalk
source