ssh "les autorisations sont trop ouvertes" erreur
J'ai eu un problème avec mon mac où je ne pouvais plus sauvegarder aucun type de fichier sur le disque . Je devais redémarrer OSX Lion et réinitialiser les permissions sur les fichiers et acls.
Mais maintenant, quand je veux valider un dépôt, l'erreur suivante apparaît 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'autorisation dois-je donner au fichier id_rsa?
Les clés doivent être lisibles uniquement par vous:
chmod 400 ~/.ssh/id_rsa
600 semble également convenir (en fait, il est préférable dans la plupart des cas, car il n'est pas nécessaire 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.
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
La solution indépendante de l'environnement local qui fonctionne sur Windows 8.1 est la suivante:
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.
Le mien est à 6 h (et ça marche)
Autant que je sache, les valeurs sont les suivantes:
700 pour le répertoire caché ".ssh" où se trouve le fichier de clé
600 pour le fichier de clés "id_rsa"
Il existe une exception à l'exigence de permission "0x00" sur une clé. Si la clé appartient à root et à un groupe contenant des utilisateurs, il peut s'agir de «0440» et tout utilisateur de ce groupe peut utiliser la clé.
Je crois que cela fonctionnera avec toutes les autorisations de 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 bien.
Cela ne se fait généralement pas pour la clé personnelle d'une personne, mais pour une clé utilisée pour l'automatisation, dans une situation où vous ne voulez pas que l'application puisse manipuler la clé.
Des règles similaires s'appliquent aux restrictions de répertoire .ssh.
fournir 400 permission, commande exécuter ci-dessous
chmod 400 /Users/username/.ssh/id_rsa
ce qui a fonctionné pour moi
dossier Utilisateurs chgrp
chmod 600 DOSSIER
J'ai eu le même problème après la migration d'un autre mac. Et ça a bloqué de connecter github par ma clé.
Je réinitialise 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-------)
Sous Windows 10, les commandes chmod et chgrp de cygwin ne me suffisaient pas. Je devais faire un clic droit sur le fichier -> Propriétés -> Sécurité (onglet) et supprimer tous les utilisateurs et groupes à l'exception de mon utilisateur actif.
Message intéressant ici ... Les systèmes d'exploitation sont suffisamment intelligents pour refuser les connexions distantes si votre clé privée est trop ouverte. Il comprend le risque que les autorisations pour id_rsa soient grandes ouvertes (en lecture, éditable par quiconque).
{On aurait pu changer votre serrure d'abord et l'ouvrir ensuite avec les clés qu'il avait déjà. }
cd ~/.ssh
chmod 400 id_rsa
PS:
Alors que nous travaillons sur plusieurs serveurs (hors production), la plupart d’entre nous estimons qu’il est nécessaire de connecter un serveur distant avec ssh. Une bonne idée est d’avoir un fragment de code de niveau d’application (éventuellement Java utilisant jsch) pour créer des approbations SSH entre serveurs. De cette façon, la connexion sera sans mot de passe. Incase, Perl est installé - on peut aussi utiliser le module net ssh.
J'ai l'erreur dans mes fenêtres 10 donc j'ai placé l'autorisation comme suit et cela fonctionne.
En détail, supprimez les autres utilisateurs/groupes jusqu'à ce qu'il ne contienne plus que "SYSTÈME" et "Administrateurs". Ajoutez ensuite votre connexion Windows avec une autorisation de lecture uniquement.
Notez que le fichier id_rsa se trouve dans le dossier c:\users\<username>.
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
J'ai essayé le niveau de permission 600 pour ma clé privée et cela a fonctionné pour moi . chmod 600 privateKey [Dev] $ ssh -i privateKey user@ipworked
chmod 755 privateKey [dev] $ ssh -i privateKey utilisateur @ ip le problème était le suivant: Les autorisations 0755 pour 'privateKey' sont trop ouvertes ..__ vos fichiers de clé privée ne sont PAS accessibles par d'autres . Cette clé privée sera ignorée . Charger la clé "privateKey": mauvaises autorisations.
J'ai rencontré cette erreur alors 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
Pour moi (en utilisant le sous-système Ubuntu pour Linux), le message d'erreur est devenu:
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 en était la raison.
Changez cela en utilisant le cmd:
ubuntu config --default-user your_username