ssh “les autorisations sont trop ouvert” erreur

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

Mais maintenant, quand je veux commettre un référentiel j'obtiens l'erreur suivante à partir 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.

Ce que les niveaux d'autorisation devrais-je donner à la id_rsa fichier?

  • Merci d'avoir posé la quesiton. Une meilleure expérience serait pour celui qui a écrit ce message d'erreur pour suggérer quelques configurations valides (comme les 600 ou 400 comme indiqué ci-dessous). Les programmeurs de ne pas écrire suffisamment complète des messages d'erreur qui sont utiles ont été torturer tous de nous depuis des années!
InformationsquelleAutor Yannick Schall | 2012-02-14
  1. 2885

    Clés doivent être lisibles seulement par vous:

    chmod 400 ~/.ssh/id_rsa

    600 semble être très bien (en fait de mieux dans la plupart des cas, parce que vous n'avez pas besoin de modifier les autorisations de fichier 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.
    • 400 est trop faible comme qui le rend non accessible en écriture par votre propre utilisateur. 600 est effectivement recommandé car il permet de propriétaire en lecture-écriture, et pas seulement lire.
    • J'ai découvert aujourd'hui il y a des moments où 400 est pertinent. Supposons que vous avez un fichier authorized_keys qui a le no-pty et al jeu de fonctionnalités. Si le fichier est accessible en écriture, l'utilisateur peut réellement remplacer le fichier authorized_keys et gain de shell interactif d'accès! Quelque chose à garder à l'esprit, mais certainement pas le cas général pour la plupart des gens.
    • arf... je me déplace le fichier... je ne veux même pas où il est, je suis juste en définissant un mot de passe. Puis-je dire ssh-keygen que je suis plus intelligent que ça, et que je n'ai pas de soins sur les autorisations juste cette fois?
    • AWS effectivement recommande l'autorisation de 400 sur leur site web. C'est ce que j'ai fait sur OS X et cela a fonctionné.
    • Cela fonctionne bien et est plus sûr. Le seul inconvénient est que vous aurez à changer de 600 à modifier. Pour id_rsa et id_rsa.pub, je doute que les questions parce que vous rarement jamais modifier ces fichiers, mais pour authorized_keys, il pourrait être gênant. Mieux comprendre le compromis et la configuration de chaque système de manière appropriée.
    • Je suppose que cela dépend aussi de combien vous êtes dans l'édition. Beaucoup de gens set it and forget it, donc 400 serait plus sûr d'autrui et de vos propres actions; de la modification de 600 lorsque cela est nécessaire. Si c'est une partie de votre flux de travail et votre ssh-savy, alors peut-être que ce serait plus un obstacle à garder la modification des autorisations.
    • IMPORTANT : Pour moi, j'étais incapable de modifier les autorisations de id_rsa à l'intérieur de .ssh dossier, j'ai donc modifié l'autorisation de celui-ci sur mon bureau puis copié sur .ssh dossier avec ce code après cd desktop utilisation cp -frp id_rsa ~/.ssh puis ajouter ssh-add -K id_rsa
    • Je lance cette commande et ça ne change rien
    • Jetez un oeil ici; cela m'a aidé aujourd'hui. Perms sur le www-utilisateurs des données du répertoire de base nécessaires pour être modifié; subtile question de l'OMI.
    • chmod 400 ne fonctionne pas pour moi, en dépit de l'absence d'avertissement ou d'erreur, le fichier des autorisations n'étaient tout simplement pas changé - comme si la commande n'a rien fait. Comme ce doit être parce que ma clé privée a été à l'intérieur d'un dossier partagé entre une machine virtuelle et son hôte de la machine (c'est à dire, chmod être comme "hey, c'est publiquement accessible, donc pas de nouvelles autorisations de fichier pour vous!"). J'ai donc déplacé la clé de ~/.ssh/private_key, chmodé il de plus dans ce dossier, à la place, et maintenant tout fonctionne.
    • Comment faire pour modifier cette autorisation dans Windows? J'ai essayé d'installer les deux répertoires et les fichiers cachés et en lecture seule, mais sans succès.
    • pour une raison quelconque, quand j'ai changé la permission de 600 ou 400 je ne peux plus accéder moi-même

    InformationsquelleAutor quickshiftin
  2. 91

    L'utilisation de Cygwin sous Windows 8.1, il y a une commande à exécuter:

    chgrp Utilisateurs ~/.ssh/id_rsa

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

    chmod 600 ~/.ssh/id_rsa

    Ref: http://vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8

    • dépendant de paramètres régionaux. J'ai dû courir "chgrp Użytkownicy ~/.ssh/id_rsa" depuis "Utilisateurs" erronées aucun groupe de ce type.
    • J'ai dû le faire ainsi. Mon cygwin répertoire a été dans l'emplacement par défaut (C:\cygwin64) donc il a probablement hérité les autorisations. Étrange que ce n'était pas le cas sur d'autres portables que j'ai possédé.
    • J'ai ajouté une réponse qui fonctionne indépendamment de paramètres régionaux: stackoverflow.com/a/28647713/67013
    • Windows 10. Utilisé la deuxième commande uniquement. A travaillé comme un charme.
    • Notez que pour les installations dans les autres langues du groupe 'Utilisateurs' a d'autres identifiants.
    • J'utilise sudo chmod 600 ~/.ssh/id_rsa. Ensuite, exécutez ssl -L xxxx id_rsa. il me demande de l'authenticité de l'hôte " ci-smartface.westeurope.cloudapp.azure.com (13.94.213.109)' ne peut pas être établie. ECDSA empreinte de clé est aaaa. Êtes-vous sûr de vouloir continuer à connecter (oui/non)?. - Je entrer "oui", même message d'erreur est exister AVERTISSEMENT: non protégée du FICHIER de CLÉ PRIVÉE! .

    InformationsquelleAutor tanza9
  3. 35

    Les paramètres régionaux indépendants solution qui fonctionne sur Windows 8.1 est:

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

    GID 545 est un ID spéciale qui se réfère toujours à "Utilisateurs" du groupe, même si vous locale utilise un autre mot pour les Utilisateurs.

    InformationsquelleAutor thehouse
  4. 30

    0600 est ce que le mien est fixé à (et ça fonctionne)

    InformationsquelleAutor Devin Ceartas
  5. 22

    Autant que je sache, les valeurs sont:

    700 pour le répertoire caché ".ssh" où le fichier clé est situé

    600 pour le fichier "id_rsa"

    InformationsquelleAutor ajaaskel
  6. 14

    Il existe une exception à la "0x00" autorisations d'exigence sur une touche. Si la clé est détenue par le root et le groupe détenu par un groupe d'utilisateurs, il peut être "0440" et tout utilisateur de ce groupe peut utiliser la clé.

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

    Ce serait généralement pas faire pour quelqu'un du personnel clé, mais pour une clé utilisée pour l'automatisation, dans une situation où vous ne voulez pas l'application pour être en mesure de jouer avec la clé.

    Des règles similaires s'appliquent à l' .ssh répertoire des restrictions.

    InformationsquelleAutor syberghost
  7. 11

    400 permission,
    exécuter la commande ci-dessous 

    chmod 400 /Users/username/.ssh/id_rsa

    ssh “les autorisations sont trop ouvert” erreur

    InformationsquelleAutor Sujit Dhamale
  8. 7

    J'ai obtenu l'erreur dans mon windows 10 alors je l'ai mis exprès, comme le suivant, et cela fonctionne.

    ssh “les autorisations sont trop ouvert” erreur

    En détails, en supprimer d'autres utilisateurs/groupes jusqu'à ce qu'il n'a qu' 'SYSTÈME' et 'Administrateurs'. Ajoutez ensuite votre identifiant windows en elle avec la permission de Lecture seulement.

    Note le id_rsa fichier est sous la c:\users\<username> dossier.

    InformationsquelleAutor Supawat Pusavanno
  9. 6

    Sur Windows 10, cygwin est chown et chgrp, n'était pas assez pour moi. J'ai dû faire un clic droit sur le fichier -> Propriétés -> Sécurité (onglet) et supprimer tous les utilisateurs et les groupes, sauf pour mon utilisateur actif.

    InformationsquelleAutor Jared Beach
  10. 4

    ce qui a fonctionné pour moi

    chgrp DOSSIER Utilisateurs

    chmod 600 DOSSIER

    • chgrp: grupo inválido: les «Utilisateurs»
    • J'ai essayé, mais garder à jeter "invalide" groupe:les Utilisateurs", pourquoi? à l'aide de Windows 10, powershell
    InformationsquelleAutor Jerome Ansia
  11. 3

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

    sudo chmod 600 path_to_your_key.pem

    alors :

    ssh -i path_to_your_key user@server_ip

    Espoir aide

    InformationsquelleAutor lansanalsm
  12. 2

    Interessant message ici.
    D'exploitation Syatems sont assez intelligents pour refuser les connexions à distance si votre clé privée est trop ouvert. Il comprend le risque où les autorisations pour id_rsa est grande ouverte (lire, est edittable par personne).

    { Que l'on peut avoir changé votre verrouillage d'abord, puis l'ouvrir avec les clés qu'il avait déjà. }

    cd ~/.ssh
chmod 400 id_rsa

    PS:

    Tout en travaillant sur de multiples serveurs (non-production), la plupart d'entre nous se sentent le besoin de se connecter serveur distant avec ssh. Une bonne idée est d'avoir une pice de niveau d'application du code (peut-être java à l'aide de jsch) pour créer ssh fiducies entre les serveurs. De cette façon connexion sans mot de passe. Encas, perl est installé, on peut utiliser net ssh module de trop.

    InformationsquelleAutor Piyush Baijal
  13. 2

    Pour moi (à l'aide de la sous-système Ubuntu Linux) le message d'erreur changé:

     Permissions 0555 for 'key.pem' are too open

    après aide de la commande chmod 400.
    Il s'avère que l'utilisation de root comme utilisateur par défaut est la raison.

    Changer cela en utilisant le cmd:

     ubuntu config --default-user your_username
    InformationsquelleAutor Daniel Kettemann
  14. 0

    J'ai tombé sur cette erreur alors que je jouais avec Ansible. J'ai changé les autorisations de la clé privée à 600 afin de résoudre ce problème. Et cela a fonctionné!

    chmod 600 .vagrant/machines/default/virtualbox/private_key
    InformationsquelleAutor vildhjarta
  15. 0

    J'ai essayé de 600 niveau d'autorisation pour ma clé privée et il a travaillé pour moi.
    chmod 600 privateKey
    [dev]$ ssh -je privateKey user@ip
    travaillé

    chmod 755 privateKey
    [dev]$ ssh -je privateKey user@ip
    qu'elle apporte à la question ci-dessous:
    Les autorisations 0755 pour "privateKey' sont trop ouvert.
    Il est nécessaire que vos fichiers de clés privées ne sont PAS accessibles par les autres.
    Cette clé privée sera ignoré.
    Chargement de la clé "privateKey": mauvaises permissions

    InformationsquelleAutor deepu kumar singh
  16. -1

    Je suis à l'aide de VPC sur EC2 et a été d'obtenir les mêmes messages d'erreur. J'ai remarqué que j'ai été en utilisant le DNS public. J'ai changé les DNS privé et vola!! il a travaillé...

    InformationsquelleAutor user3195783
  17. -3

    pour Win10 besoin de déplacer votre clé à l'accueil de l'utilisateur dir
    pour linuxlike os vous avez besoin de faire un chmod 700 aime ou 600 etc.

    InformationsquelleAutor Fedulov Oleg