ssh «les autorisations sont trop ouvertes»


2056

J'ai eu un problème avec mon mac où je ne pouvais plus enregistrer aucun type de fichier sur le disque. J'ai dû redémarrer OSX lion et réinitialiser les autorisations sur les fichiers et les acls.

Mais maintenant, quand je veux valider un référentiel, j'obtiens l'erreur suivante de ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Quels niveaux d'autorisations dois-je accorder au fichier id_rsa?


21
Merci d'avoir posé la question. Une meilleure expérience serait pour celui qui a écrit ce message d'erreur de suggérer quelques configurations valides (telles que 600 ou 400 comme suggéré ci-dessous). Les programmeurs qui n'écrivent pas de messages d'erreur suffisamment complets et utiles nous torturent tous depuis des années!
George Pligoropoulos

FWIW, cela est lié à StrictModesêtre activé sur le sshdserveur, de l' homme page: « StrictModes Indique si sshd (8) doit vérifier les modes de fichiers et la propriété des fichiers de l'utilisateur et le répertoire home avant d' accepter la connexion. » - vous pouvez désactiver cela mais pas suggéré.
masseyb

Réponses:


3475

Les clés doivent être uniquement lisibles par vous:

chmod 400 ~/.ssh/id_rsa

Si vous devez lire les clés en écriture:

chmod 600 ~/.ssh/id_rsa

600 semble également convenir (en fait mieux dans la plupart des cas, car vous n'avez pas besoin de modifier les autorisations de fichier plus tard pour le modifier).

La partie pertinente de la page de manuel ( man ssh)

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.

300
400 est trop faible car cela le rend non inscriptible par votre propre utilisateur. 600 est en fait recommandé car il permet au propriétaire de lire-écrire et pas seulement de lire.
jfreak53

8
J'ai découvert aujourd'hui qu'il y a des moments où 400 est pertinent. Supposons que vous ayez un fichier authorized_keys ayant les fonctionnalités no-pty et al . Si le fichier est accessible en écriture, l'utilisateur peut réellement écraser le fichier authorized_keys et accéder au shell interactif! Quelque chose à garder à l'esprit, mais qui n'est sûrement pas le cas général de la plupart des gens.
quickshiftin

17
AWS recommande en fait l'autorisation 400 sur son site Web. C'est ce que j'ai fait sur OS X et cela a fonctionné.
George Mylonas

5
Cela fonctionne certainement et est plus sûr. Le seul inconvénient est que vous devez ensuite le changer en 600 pour le modifier. Pour id_rsa et id_rsa.pub, je doute que ce soit important, car il est rare que vous éditiez ces fichiers, mais pour authorized_keys, cela pourrait être ennuyeux. Mieux vaut comprendre les compromis et configurer chaque système de manière appropriée.
quickshiftin

3
Je suppose que cela dépend aussi de la fréquence à laquelle vous les modifiez. Beaucoup de gens le définissent et l'oublient, ainsi 400 seraient plus à l'abri des autres et de vos propres actions; modification à 600 si nécessaire. Si cela fait partie de votre flux de travail et de votre ssh-savy, alors ce serait peut-être plus un obstacle de continuer à changer les autorisations.
vol7ron

99

En utilisant Cygwin dans Windows 8.1, une commande doit être exécutée:

Utilisateurs chgrp ~ / .ssh / id_rsa

Ensuite, la solution affichée ici peut être appliquée, 400 ou 600 est OK.

chmod 600 ~ / .ssh / id_rsa

Réf: http://vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8


8
dépend des paramètres régionaux. J'ai dû exécuter "chgrp Użytkownicy ~ / .ssh / id_rsa" car "Users" n'a commis aucune erreur de ce type.
Marcos

Je devais aussi faire ça. Mon répertoire cygwin se trouvait à l'emplacement par défaut ( C:\cygwin64), il a donc probablement hérité des autorisations. C'est étrange que cela ne se soit pas produit sur les autres ordinateurs portables que j'ai possédés.
Zach Thacker

3
@Marcos J'ai ajouté une réponse qui fonctionne indépendamment des paramètres régionaux: stackoverflow.com/a/28647713/67013
thehouse

4
Windows 10. Utilisé la deuxième commande uniquement. A fonctionné comme un charme.
StalkAlex

Notez que pour les installations dans d'autres langues, le groupe «Utilisateurs» a des identifiants alternatifs.
John Rumpel du

43

La solution indépendante des paramètres régionaux qui fonctionne sur Windows 8.1 est:

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

Le GID 545 est un ID spécial qui fait toujours référence au groupe «Utilisateurs», même si vos paramètres régionaux utilisent un mot différent pour les utilisateurs.



24

AFAIK les valeurs sont:

700 pour le répertoire caché ".ssh" où se trouve le fichier de clé

600 pour le fichier de clés "id_rsa"


19

J'ai l'erreur dans mes fenêtres 10, j'ai donc défini l'autorisation comme suit et cela fonctionne.

Autorisation pour id_rsa de Windows 10

Dans les détails, supprimez les autres utilisateurs / groupes jusqu'à ce qu'il ne contienne que «SYSTEM» et «Administrators». Ajoutez ensuite votre connexion Windows avec l'autorisation de lecture uniquement.

Notez que le id_rsafichier se trouve dans le c:\users\<username>dossier.


J'ai le même problème sur Win-10. Sur la base de votre explication, ne savez pas exactement ce que vous avez réellement autorisé et refusé - j'ai "utilisateurs" et "utilisateurs authentifiés" et non "utilisateur spécifique" comme options + Système et administrateurs. De plus, je ne pouvais pas comprendre cygwin - à installer ou à utiliser. (?)
Sam-T

2
pour Win10, vous devez déplacer votre clé au domicile de l'utilisateur - cela a parfaitement fonctionné. J'essayais de donner le chemin d'accès complet à la clé et de jouer avec les autorisations - rien ne fonctionnait.
Sam-T

@ Sam-T si vous ne voyez pas votre nom dans la liste, vous pouvez ajouter en appuyant sur Edit...puis appuyez sur Add...puis tapez votre nom dans la zone de texte "Enter the object names to select"puis appuyez sur le Check Namesbouton (et appuyez sur OKet sur un autre OK), puis votre nom doit être répertorié dans l' Securityonglet
Supawat Pusavanno

Je peux probablement ajouter le nom spécifiquement - selon vos instructions. Mais ma question principale était - quelles autorisations exactes refuser et autoriser pour tous . Pendant ce temps, comme mentionné, j'ai pu résoudre le problème en ajoutant simplement .pemlemyuser directory
Sam-T

16

Il existe une exception à l'exigence d'autorisations "0x00" sur une clé. Si la clé appartient à root et appartient à un groupe appartenant à un groupe contenant des utilisateurs, elle peut être "0440" et tout utilisateur de ce groupe peut utiliser la clé.

Je crois que cela fonctionnera avec toutes les autorisations dans l'ensemble "0xx0" mais je n'ai pas testé chaque combinaison avec chaque version. J'ai essayé 0660 avec 5.3p1-84 sur CentOS 6, et le groupe n'est pas le groupe principal de l'utilisateur mais un groupe secondaire, et cela fonctionne très bien.

Cela ne serait généralement pas fait pour la clé personnelle de quelqu'un, mais pour une clé utilisée pour l'automatisation, dans une situation où vous ne voulez pas que l'application puisse jouer avec la clé.

Des règles similaires s'appliquent aux restrictions du répertoire .ssh.


15

fournir 400 autorisations, exécuter la commande ci-dessous

chmod 400 /Users/username/.ssh/id_rsa

entrez la description de l'image ici


génial! Cela a résolu le problème pour moi. Je vous remercie!
Emanuela Colta

11

Sur Windows 10, chmod et chgrp de cygwin ne me suffisaient pas. J'ai dû faire un clic droit sur le fichier -> Propriétés -> Sécurité (onglet) et supprimer tous les utilisateurs et groupes sauf mon utilisateur actif.


C'est la seule solution qui fonctionne :) Merci d'avoir économisé mon temps
Atul

J'ai constaté qu'après cela, je pouvais également faire ssh à partir de l'invite de commande Windows normale. Pas besoin d'utiliser Cygwin. Génial!
Atul

8

C'est ce qui a fonctionné pour moi (sur mac)

sudo chmod 600 path_to_your_key.pem 

puis :

ssh -i path_to_your_key user@server_ip

J'espère que ça aide



4

J'ai eu le même problème après la migration d'un autre Mac. Et il a bloqué la connexion de github par ma clé.

J'ai réinitialisé l'autorisation comme ci-dessous et cela fonctionne bien maintenant.

chmod 700 ~/.ssh     # (drwx------)
cd ~/.ssh            
chmod 644 *.pub      # (-rw-r--r--)
chmod 600 id_rsa     # (-rw-------)

4

Windows 10 ssh dans Ubuntu EC2 «Les autorisations sont trop ouvertes» sur AWS

J'ai eu ce problème en essayant de ssh dans une instance Ubuntu EC2 en utilisant le fichier .pem d'AWS.

Dans Windows, cela a fonctionné lorsque j'ai mis cette clé dans un fichier créé sous le dossier .ssh

C:\Users\USERNAME\.ssh\private_key

Pour modifier les paramètres d'autorisation dans Windows 10:

Paramètres des fichiers> Sécurité> Avancé

Désactiver l'héritage

Convertir les autorisations héritées en autorisations explicites

Supprimez toutes les entrées d'autorisation à l'exception des administrateurs

Pourrait alors se connecter en toute sécurité.


4

Pour moi (en utilisant le sous-système Ubuntu pour Windows), le message d'erreur a changé en:

 Permissions 0555 for 'key.pem' are too open

après avoir utilisé chmod 400. Il s'avère que l'utilisation de root comme utilisateur par défaut était la raison.

Modifiez cela en utilisant la cmd:

 ubuntu config --default-user your_username

3

Message intéressant ici. Les systèmes d'exploitation sont suffisamment intelligents pour refuser les connexions à distance si votre clé privée est trop ouverte. Il comprend le risque lorsque les autorisations pour id_rsa sont grandes ouvertes (lues, modifiables par n'importe qui).

{On peut d'abord changer votre serrure puis l'ouvrir avec les clés qu'il a déjà}

cd ~/.ssh
chmod 400 id_rsa

Tout en travaillant sur plusieurs serveurs (hors production), la plupart d'entre nous ressentent le besoin de connecter un serveur distant avec ssh. Une bonne idée est d'avoir un morceau de code au niveau de l'application (peut être java en utilisant jsch) pour créer des approbations ssh entre les serveurs. De cette façon, la connexion sera sans mot de passe. Au cas où, perl est installé - on peut aussi utiliser le module net ssh.


1

J'ai rencontré cette erreur pendant que je jouais avec Ansible. J'ai changé les autorisations de la clé privée en 600 afin de résoudre ce problème. Et ça a marché!

chmod 600 .vagrant/machines/default/virtualbox/private_key

1

J'ai essayé 600 niveaux d'autorisation pour ma clé privée et cela a fonctionné pour moi. chmod 600 privateKey [dev] $ ssh -i privateKey user @ ip works

chmod 755 privateKey [dev] $ ssh -i privateKey user @ ip il donnait le problème ci-dessous: Les autorisations 0755 pour 'privateKey' sont trop ouvertes. Il est nécessaire que vos fichiers de clés privées ne soient PAS accessibles aux autres. Cette clé privée sera ignorée. Charger la clé "privateKey": mauvaises autorisations


0
I have got the similar issue when i was trying to login to remote ftp server using public keys..        
To solve this issue initially i have done the following process
    Trouvez d'abord l'emplacement des clés publiques car lorsque vous essayez de vous connecter à ftp en utilisant cette clé publique. nous devons d'abord créer une clé et nous définissons pour définir les autorisations de clés à 600.
            Assurez-vous que vous êtes au bon endroit.
            étape 1:
            aller au bon endroit
            étape 2:
            Une fois que vous êtes au bon endroit
 commander: 
     chmod 600 id_rsa

        This has solved my issue.


-2

pour Win10, vous devez déplacer votre clé vers le répertoire d'accueil de l'utilisateur pour les systèmes d'exploitation linux, vous devez passer à 700 comme ou 600, etc.


pour Win10, vous devez déplacer votre clé au domicile de l'utilisateur - cela a parfaitement fonctionné. J'essayais de donner le chemin d'accès complet à la clé et de jouer avec les autorisations - n'a pas fonctionné.
Sam-T
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.