Récemment, j’ai été incapable de cloner ou d’appuyer sur github, et j’essaie de trouver la cause.
C'est sur windows
J'ai cygwin + git ainsi que msysgit.
Msysgit a été installé avec les options suivantes:
Cela me donne 4 environnements pour essayer d'utiliser git dans:
D'une manière ou d'une autre, j'ai réussi à me trouver dans une position où, lorsque j'essaie de cloner un référentiel à l'aide de msysgit, cmd.exe ou Powershell, j'obtiens le message d'erreur suivant:
> Initialized empty Git repository in
> C:/sandbox/SomeProject/.git/
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0644 for
> '/c/Users/Ben/.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. bad permissions: ignore key:
> /c/Users/Ben/.ssh/id_rsa Permission
> denied (publickey). fatal: The remote
> end hung up unexpectedly
Ceci utilise le dossier .ssh de mon dossier c:\users\ben \, utilisé par msysgit. Je suppose que cygwin fonctionne car le dossier .ssh est situé ailleurs, mais je ne sais pas pourquoi
Dans Git Bash, je vérifie les autorisations:
$ ls -l -a ~/.ssh
Ce qui me donne:
drwxr-xr-x 2 Ben Administ 0 Oct 12 13:09 .
drwxr-xr-x 34 Ben Administ 8192 Oct 12 13:15 ..
-rw-r--r-- 1 Ben Administ 1743 Oct 12 12:36 id_rsa
-rw-r--r-- 1 Ben Administ 399 Oct 12 12:36 id_rsa.pub
-rw-r--r-- 1 Ben Administ 407 Oct 12 13:09 known_hosts
Ces autorisations sont apparemment trop détendues. Comment ils ont eu cette façon, je n'en ai aucune idée.
Je peux essayer de les changer ...
$ chmod -v -R 600 ~/.ssh
qui me dit:
mode of `.ssh' changed to 0600 (rw-------)
mode of `.ssh/id_rsa' changed to 0600 (rw-------)
mode of `.ssh/id_rsa.pub' changed to 0600 (rw-------)
mode of `.ssh/known_hosts' changed to 0600 (rw-------)
Mais cela semble n'avoir aucun effet. J'ai toujours la même erreur, et en faisant
$ ls -l -a ~/.ssh
donne les mêmes autorisations que précédemment.
UPDATE:
J'ai essayé de corriger les autorisations sur ces fichiers dans cygwin, et cygwin signale correctement leurs autorisations, mais pas gitbash: alt text http://cdn.cloudfiles.mosso.com/c54102/app7962031255448924.jpg
Des idées sur la façon dont je peux vraiment corriger ces autorisations?
Vous avez modifié les autorisations sur l'ensemble du répertoire, ce qui, je suis d'accord avec Splash, est une mauvaise idée. Si vous vous souvenez des autorisations d'origine du répertoire, j'essaierai de les rétablir, puis procédez comme suit:
cd ~/.ssh
chmod 700 id_rsa
dans le dossier .ssh. Cela définira le fichier id_rsa sur rwx (lecture, écriture, exécution) pour le propriétaire (vous) uniquement et avec un accès nul pour tous les autres.
Si vous ne vous souvenez plus des paramètres d'origine, ajoutez un nouvel utilisateur et créez un ensemble de clés SSH pour cet utilisateur, créant ainsi un nouveau dossier .ssh doté d'autorisations par défaut. Vous pouvez utiliser ce nouveau dossier .ssh comme référence pour les autorisations permettant de réinitialiser votre dossier et vos fichiers .ssh.
Si cela ne fonctionne pas, j’essayerais de désinstaller msysgit en supprimant TOUS les dossiers .ssh de l’ordinateur (juste par mesure de sécurité), puis en réinstallant msysgit avec les paramètres de votre choix et d’essayer de tout recommencer à zéro (bien que je pense que vous vous avez déjà essayé cela).
Édité: Je viens également de trouver ce lien via Google - Correction de "AVERTISSEMENT: FICHIER DE CLÉ PRIVÉE NON PROTÉGÉ!" Sous Linux Même s’il est destiné à Linux, cela pourrait aider car nous parlons d’autorisations liunx et autres.
Il y a un bug avec le chmod de cygwin, veuillez vous référer à:
https://superuser.com/questions/397288/using-cygwin-in-windows-8-chmod-600-does-not-work-as-expected
chgrp -Rv Users ~/.ssh/*
chmod -vR 600 ~/.ssh/id_rsa
Pour les systèmes * nix, le correctif évident est chmod 600 id_rsa
ofc, mais sous Windows 7, j'ai dû me cogner la tête contre le mur pendant un moment, mais j'ai ensuite trouvé la solution magique:
allez à Poste de travail/Clic droit/Propriétés/Paramètres système avancés/Variables d'environnement et DELETE la variable (éventuellement des environnements système et utilisateur):
CYGWIN
En gros, c’est une faille dans mingw32 utilisé par git windows binary, voir tous les fichiers 644 et tous les dossiers 755 toujours. La suppression de la variable d'environnement ne modifie pas ce comportement, mais elle indique apparemment à ssh.exe d'ignorer le problème. Si vous définissez les autorisations appropriées sur votre id_rsa via les paramètres de sécurité des explorateurs (il n'est vraiment pas nécessaire que vous ayez un autre utilisateur que le vôtre, ni "tout le monde", ni "les administrateurs", ni le "système". , vous serez toujours en sécurité.
Maintenant, pourquoi mingw32, un système différent de cygwin, ferait toute utilisation de la variable d’environnement CYGWIN, m’est dépassé. Ça ressemble à un insecte pour moi.
Je suis sur XP et cela a permis à Git Bash de communiquer avec Github (après beaucoup de frustration):
c:\cygwin\bin\cyg*
(~ 50 fichiers) dans c:\Program Files\Git\bin\
c:\cygwin\bin\ssh.exe
dans c:\Program Files\Git\bin\
(écrasement)Créez le fichier c:\Documents and Settings\<username>\.ssh\config
contenant:
Host github.com
User git
Hostname github.com
PreferredAuthentications publickey
IdentityFile "/cygdrive/c/Documents and Settings/<username>/.ssh/id_rsa"
(facultatif) Utilisez ssh -v git@github
pour voir la connexion déboguée.
Contexte: Le problème général est une combinaison des deux:
Pour Windows 7 utilisant le Git trouvé ici (il utilise MinGW, pas Cygwin):
La modification des autorisations de fichiers à partir de Propriétés, la désactivation de l'héritage et l'exécution de chmod 400 ne fonctionnaient pas pour moi. Les autorisations pour mon fichier de clé privée étaient:
-r - r ----- 1 alex Aucun 1766 8 mars 13:04 /home/alex/.ssh/id_rsa
Puis j'ai remarqué que le groupe était Aucun, alors j'ai juste couru
chown alex: Administrateurs ~/.ssh/id_rsa
Ensuite, j'ai pu modifier les autorisations avec chmod 400 et exécuter un git Push.
OK, voici comment j'ai forcé la modification de mes fichiers Windows en ce qui concerne les autorisations sur Win7: Trouvez votre clé ssh dans l'explorateur Windows: C:\Utilisateurs [votre_nom_utilisateur_ici] .ssh\id_rsa
Cliquez avec le bouton droit sur fichier> Propriétés> onglet Sécurité> bouton Avancé> Modifier les autorisations.
Maintenant, supprimez tout le monde qui n'est pas réellement votre nom d'utilisateur. Cela inclut les utilisateurs administrateur et système. À ce stade, vous pouvez entamer un dialogue sur l'héritage des autorisations. Choisissez l'option à ne pas hériter. Nous souhaitons uniquement modifier ce fichier.
Cliquez sur OK et sauvegardez jusqu'à la fin.
Je me suis battu avec ce pendant des jours parce que mes fenêtres ne changeraient pas les autorisations de fichier de la ligne de commande. De cette façon, il est également réellement fait - au lieu d’utiliser des contournements passionnants qui peuvent avoir des conséquences étranges.
POUR LES UTILISATEURS MAC:
Modifiez les paramètres de votre fichier de paire de clés en le saisissant dans le terminal:
chmod og-r *filename.pem*
(assurez-vous que vous êtes dans le bon répertoire ou que le chemin est le nom du fichier dans la commande).
Je le résous en cours d'exécution:
chmod 400 ~/.ssh/id_rsa
J'espère aider. Bonne chance.
J'ai eu le même problème sur Windows XP tout récemment. J'ai essayé de chmod 700 sur mon fichier ~/.ssh/id_rsa mais cela n'a pas semblé fonctionner. Lorsque j'ai jeté un œil sur les autorisations utilisant ls -l sur ~/.ssh/id_rsa, j'ai constaté que mes autorisations effectives étaient toujours de 644.
Ensuite, je me suis rappelé que les autorisations Windows héritent également des autorisations des dossiers et que le dossier est toujours ouvert à tout le monde. Une solution pourrait également être de définir des autorisations pour le dossier, mais je pense qu'un meilleur moyen serait d'indiquer au système d'ignorer l'héritage pour ce fichier. Cela peut être fait en utilisant l'option avancée de l'onglet Sécurité dans les propriétés du fichier et en décochant "hériter des autorisations parent ...".
Cela pourrait être utile pour les autres avec le même problème.
Après avoir rencontré le problème récemment et ce résultat étant l'un des meilleurs résultats de Google, je pensais pouvoir y participer avec un simple travail documenté dans la discussion: http://code.google.com/p/msysgit/issues/detail? id = 261 # c4
Cela implique simplement de remplacer mysys ssh.exe par votre cygwin ssh.exe
J'ai pu résoudre ce problème en faisant deux choses, bien que vous n'ayez peut-être pas à effectuer l'étape 1.
copier à partir de cygwin ssh.exe et de tous les fichiers cyg * .dll dans le répertoire bin de Git (ce n'est peut-être pas nécessaire, mais c'est une étape que j'ai prise, mais cela seul n'a pas corrigé les choses)
suivez les étapes à partir de: http://zylstra.wordpress.com/2008/08/29/overcome-herokus-permission-denied-publickey-problem/
J'ai ajouté quelques détails à mon fichier ~/.ssh/config:
Héberger sur heroku.com
Nom d'hôte heroku.com
Port 22
IdentitiesOnly yes
IdentityFile ~/.ssh/id_heroku
TCPKeepAlive oui
Utilisateur brandon
J'ai dû utiliser User comme adresse électronique pour heroku.com. Remarque: cela signifie que vous devez créer une clé. J'ai ensuite suivi cette procédure pour créer la clé. Lorsque le nom de la clé est demandé, veillez à spécifier id_heroku http://help.github.com/win-set-up-git/
Le truc pour moi a été de mettre à jour la variable d’environnement CYGWIN avec: " tty nodosfilewarning = ". Je n'ai même pas eu besoin de chmod la clé.
Ceci est un problème particulièrement impliqué sous Windows, où il ne suffit pas de chmoder les fichiers correctement. Vous devez configurer votre environnement.
Sous Windows, cela a fonctionné pour moi:
Installez cygwin.
Remplacez le fichier msysgit ssh.exe par le fichier ssh.exe de cygwin.
En utilisant cygwin bash, chmod 600 le fichier de clé privée, qui était "id_rsa" pour moi.
Si cela ne fonctionne toujours pas, allez dans Panneau de configuration -> Propriétés système -> Avancé -> Variables d'environnement et ajoutez la variable d'environnement suivante. Ensuite, répétez l'étape 3.
Valeur variable
CYGWIN sbmntsec
Je joue actuellement avec Git 1.6.5, et je ne peux pas répliquer votre configuration:
Administrator@WS2008 /k/git
$ ll ~/.ssh
total 8
drwxr-xr-x 2 Administ Administ 4096 Oct 13 22:04 ./
drwxr-xr-x 6 Administ Administ 4096 Oct 6 21:36 ../
-rw-r--r-- 1 Administ Administ 0 Oct 13 22:04 c.txt
-rw-r--r-- 1 Administ Administ 403 Sep 30 22:36 config_disabled
-rw-r--r-- 1 Administ Administ 887 Aug 30 16:33 id_rsa
-rw-r--r-- 1 Administ Administ 226 Aug 30 16:34 id_rsa.pub
-rw-r--r-- 1 Administ Administ 843 Aug 30 16:32 id_rsa_PuTTY.ppk
-rw-r--r-- 1 Administ Administ 294 Aug 30 16:33 id_rsa_PuTTY.pub
-rw-r--r-- 1 Administ Administ 1626 Sep 30 22:49 known_hosts
Administrator@WS2008 /k/git
$ git clone [email protected]:alexandrul/gitbook.git
Initialized empty Git repository in k:/git/gitbook/.git/
remote: Counting objects: 1152, done.
remote: Compressing objects: 100% (625/625), done.
remote: Total 1152 (delta 438), reused 1056 (delta 383)s
Receiving objects: 100% (1152/1152), 1.31 MiB | 78 KiB/s, done.
Resolving deltas: 100% (438/438), done.
Administrator@WS2008 /k/git
$ ssh [email protected]
ERROR: Hi alexandrul! You've successfully authenticated, but GitHub does not pro
vide Shell access
Connection to github.com closed.
$ ssh -v
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
chmod ne modifie pas non plus les permissions de fichiers pour mes clés.
Environnement:
Mise à jour: Git 1.6.5.1 fonctionne également.
Tapez sur le terminal:
chmod -Rf 700 ~/.ssh/
Et essayez à nouveau.
Mon système est un peu en désordre avec bash/cygwin/git/msysgit/peut-être-plus ...
chmod
n'a eu aucun effet sur la clé, ni sur le fichier config
.
Ensuite, j'ai décidé de l'aborder à partir de Windows, ce qui a fonctionné.
Properties
.Security
.Advanced
près du bas.Change
, à côté de Owner
près du sommet.Check Names
, puis sur OK
.Permission entries:
, mettez en surbrillance chaque utilisateur qui n'est pas "My-Awesome-Username", puis sélectionnez Remove
. Répétez cette opération jusqu'à ce qu'il ne reste plus que "My-Awesome-Username".Edit
ci-dessous.Type:
en haut est défini sur Allow
, puis cochez la case en regard de Full control
.Appuyez sur OK
, Apply
, OK
, OK
.
Faites un autre essai maintenant ...
Il semble que parfois le mock-bash ne peut pas contrôler la propriété du fichier. C'est particulièrement étrange, car il est généré à partir d'un script mock-bash. Allez comprendre.
La réponse de @ koby ne fonctionne pas pour moi, alors je fais un petit changement.
cd ~/.ssh
chmod 700 id_rsa.pub
Cela fonctionne bien pour moi sur Mac.
À moins que vous ne souhaitiez conserver cette paire de clés privée/publique (id_rsa/id_rsa.pub) ou que vous souhaitiez vous taper la tête contre un mur, je vous recommande de les recréer et de mettre à jour votre clé publique sur github.
Commencez par créer une copie de sauvegarde de votre répertoire ~/.ssh.
Entrez ce qui suit et répondez "y" si vous souhaitez écraser les fichiers existants.
ssh-keygen -t rsa
Copiez le contenu de la clé publique dans votre presse-papiers. (Vous trouverez ci-dessous comment procéder sur un Mac).
cat ~/.ssh/id_rsa.pub | pbcopy
Accédez à votre compte sur github et ajoutez cette clé.
Name: My new public key
Key: <PASTE>
Quittez votre terminal et redémarrez-en un nouveau.
Si vous recevez des messages d'erreur insensés du type "Entrez votre mot de passe" pour votre clé publique alors que vous n'en avez jamais entré, envisagez cette technique. Comme vous le voyez ci-dessus, ce n'est pas compliqué.
Avez-vous copié le fichier de clé depuis une autre machine?
Je viens de créer un fichier id_rsa
sur la machine cliente, puis j'ai collé la clé que je voulais. Aucun problème de permissions. Rien à définir. Cela a juste fonctionné. Cela fonctionne également si vous utilisez PuTTYgen pour créer la clé privée.
Peut-être un problème de groupe caché si vous le copiez depuis un autre ordinateur.
Testé sur deux machines Windows 8.1. Utilisation de Sublime Text 3 pour copier et coller la clé privée. Utiliser Git Bash (Git-1.9.4-preview20140611).
Pas une réponse directe à la question principale, mais à votre question sur le fonctionnement du dossier de cygwin ... En règle générale, cygwin place tous les "vos" fichiers sous l’équivalent de c:\cygwin\home\nomutilisateur. Il traite ce dossier pour tous les paramètres spécifiques à l'utilisateur plutôt que pour le répertoire d'utilisateurs Windows.
J'ai eu le même problème sur Windows 10 où j'ai essayé de SSH dans une boîte Vagrant. Cela ressemble à un bogue dans l'ancienne version d'OpenSSH. Ce qui a fonctionné pour moi:
(Notez le ".exe" si vous utilisez Powershell)
Vous pourriez voir quelque chose comme:
C:\Windows\System32\OpenSSH\ssh.exe
C:\Program Files\OpenSSH\bin\ssh.exe
C:\opscode\chefdk\embedded\git\usr\bin\ssh.exe
Notez que dans l'exemple ci-dessus, le dernier OpenSSH est le deuxième dans le chemin afin qu'il ne s'exécute pas.
Pour changer la commande:
Après la mise à niveau de mon installation Cygwin vers une version vers février 2015 (1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin
), j'ai soudainement rencontré l'avertissement UNPROTECTED PRIVATE KEY FILE
.
J'ai résolu ce problème après avoir exécuté la commande suivante:
setfacl -s u::rw-,g::---,o:--- ~/.ssh/id_rsa
( ne autre réponse à une autre question donne plus de contexte)
Je n'ai jamais réussi à obtenir que ce soit génial de travailler complètement à Powershell. Mais dans le shell git bash, je n’avais aucun problème lié aux autorisations, et je n’avais pas besoin de configurer chmod, etc. Après l’ajout de ssh à Github, j’étais opérationnel.