Les autorisations de clé privée SSH utilisant Git GUI ou ssh-keygen sont trop ouvertes


244

Récemment, je n'ai pas pu cloner ou pousser vers github, et j'essaie de trouver la cause première.

C'est sur windows

J'ai cygwin + git ainsi que msysgit.

Msysgit a été installé avec les options suivantes:

  • OpenSSH
  • Utiliser Git à partir de l'invite de commandes Windows

Cela me donne 4 environnements pour essayer d'utiliser git dans:

  • Invite cmd de Windows
  • Powershell
  • Git Bash
  • Cygwin

D'une manière ou d'une autre, j'ai réussi à me mettre dans une position où lorsque j'essaie de cloner un référentiel à l'aide de msysgit, cmd.exe ou Powershell, j'obtiens l'erreur suivante:

> 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

Cela utilise le dossier .ssh dans mon dossier c: \ users \ ben \, qui est utilisé par msysgit. Je soupçonne que cygwin fonctionne parce que 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 sont arrivés de cette façon, je n'en ai aucune idée.

Je peux essayer de les changer ...

$ chmod -v -R 600 ~/.ssh

ce 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. Je reçois toujours la même erreur, et en faisant

$ ls -l -a ~/.ssh

donne les mêmes autorisations qu'auparavant.

METTRE À JOUR:

J'ai essayé de corriger les autorisations sur ces fichiers dans cygwin, et cygwin signale leurs autorisations correctement, gitbash ne le fait pas: alt text http://cdn.cloudfiles.mosso.com/c54102/app7962031255448924.jpg

Des idées sur la façon dont je peux vraiment réparer ces autorisations?


1
Vous voudrez peut-être nous dire quel est le système de fichiers natif que C: \ Users \ Ben \ utilise. Il semble que ce système de fichiers ne prend pas en charge les autorisations réelles ou que les mappages entre le shell et le système de fichiers ne fonctionnent pas correctement. Pouvez-vous modifier les autorisations via les ACL Windows?
Chen Levy,

J'utilise Windows 7. Je peux modifier les autorisations pour cela, mais que sont-elles censées être? Tous les documents github / ssh disent que vous avez besoin de 0600, mais je n'ai aucune idée de ce que cela signifie dans les ACL Windows.
Ben Scheirman

2
Euh ... un peu ici, mais changer un répertoire en 600 est une mauvaise idée. Les répertoires (et les fichiers exécutables) sont toujours supérieurs d'un chiffre (700 pas 600, 755 pas 644). Faire cela sur un répertoire le rendra non répertoriable. Voir dartmouth.edu/~rc/help/faq/permissions.html pour des explications plus détaillées.
Mark Embling

Êtes-vous opposé à l'utilisation de PuTTY?
Greg Bacon

si cela résout mon problème, non, mais je suis curieux de savoir pourquoi cette configuration ne fonctionne pas pour moi.
Ben Scheirman

Réponses:


361

Vous avez modifié les autorisations sur l'ensemble du répertoire, ce que je suis d'accord avec Splash est une mauvaise idée. Si vous vous souvenez quelles sont les autorisations d'origine pour le répertoire, j'essayerais de les redéfinir sur cela, puis de procéder 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 un accès nul pour tous les autres.

Si vous ne vous souvenez pas 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 qui aura les 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'essaierais de faire une désinstallation de msysgit, de supprimer TOUS les dossiers .ssh sur l'ordinateur (juste pour des raisons de sécurité), puis de réinstaller msysgit avec les paramètres souhaités et d'essayer de recommencer complètement (bien que je pense que vous me l'ayez dit vous avez déjà essayé).

Modifié: J'ai également trouvé ce lien via Google - Correction de "AVERTISSEMENT: FICHIER CLÉ PRIVÉ NON PROTÉGÉ!" sous Linux Bien qu'il soit destiné à linux, cela pourrait aider car nous parlons d'autorisations liunx et autres.


2
Cette réponse s'applique spécifiquement à l'utilisation de cygwin ou msysgit (puisque msysgit utilise un sous-ensemble de cygwin ou peut-être mingw32). Le problème est l'autorisation sur le fichier. Git aime travailler avec (principalement) des autorisations Linux (probablement un sous-produit de son public cible). L'utilisation de git.exe dans le shell Winodws est connue pour avoir des problèmes, je vous conseille de rester avec msysgit. Au moins jusqu'à ce que GitSharp fonctionne pleinement.
Koby

2
Cela ne fonctionne pas sur Windows 8 et mon installation de janvier 2014 de cygwin comme après chmod 700, il montre le fichier comme rwxrwx ---. Les autorisations de groupe à définir sur tout ce sur quoi je définis les autorisations utilisateur et je ne peux pas utiliser mes clés.
Dean Hiller

1
@DeanHiller, une autorisation de 700 devrait ressembler -rwx------. Donc ce que vous montrez n'est pas correct si vous avez correctement exécuté la commande chmod.
Koby

5
@Koby non, c'était un bug avec un travail aroudn ... besoin d'utiliser chgrp -R Users ~ / .ssh puis chmod fonctionne maintenant et modifie les autorisations correctement ..... un bug connu sur lequel j'ai finalement trouvé un autre poste.
Dean Hiller

2
Je peux vérifier qu'il existe une sorte de bogue dans GitBash pour Windows où les autorisations correctes NE PEUVENT PAS être définies avec chmod, ou les autorisations ne sont pas lues correctement. chmod 600 id_rsd; ls -l id_rs -> -rwx-r - r--
Charlweed

74

Il y a un bug avec le chmod de cygwin, veuillez vous référer à:

/superuser/397288/using-cygwin-in-windows-8-chmod-600-does-not-work-as-expected

chgrp -Rv Users ~/.ssh/* 
chmod -vR 600 ~/.ssh/id_rsa

Pour une raison quelconque, le mappage des autorisations Windows aux autorisations de type cygwin / * nix est un peu flou. Même si j'ai supprimé toutes les autorisations des autres utilisateurs du côté Windows, cygwin a quand même appliqué les autorisations pour moi, l' utilisateur , à un autre groupe nommé None. (Je suppose que c'est la procédure normale lorsqu'un groupe n'a pas été explicitement défini) .Ce changement de groupe à un explicite Userssoi - disant permis Cygwin pour séparer les autorisations, et je pouvais enfin mettre 600 au lieu d'un 660. automatique
t-mart

3
Ceci est la vraie bonne réponse. Celui qui a été voté comme la bonne réponse - je pense que les personnes qui ont voté pour cela étaient des utilisateurs de Linux et ne se rendaient pas compte qu'il exécutait correctement la commande. J'ai eu le même problème avec cygwin aujourd'hui. Merci!
michaelday

Avant d'appliquer cette solution, lorsque j'utilisais chmod 600git , je me plaignais que mes autorisations étaient toujours 0660. La correction de la propriété du groupe fait que chown s'applique correctement.
Guilherme Rodrigues

1
J'ai mis à jour Cygwin et cela a fonctionné. Ils doivent avoir corrigé le bogue.
Duncan Calvert

17

Pour les systèmes * nix, la solution évidente est chmod 600 id_rsaofc, mais sur Windows 7, j'ai dû me frapper la tête contre le mur pendant un certain temps, mais j'ai trouvé la solution magique:

allez dans Poste de travail / Clic droit / Propriétés / Paramètres système avancés / Variables d'environnement et SUPPRIMEZ la variable (éventuellement à la fois du système et de l'environnement utilisateur):

CYGWIN

Fondamentalement, c'est une faille dans mingw32 utilisé par git windows binary, voyant toujours tous les fichiers 644 et tous les dossiers 755. La suppression de la variable d'environnement ne change pas ce comportement, mais elle indique apparemment à ssh.exe d'ignorer le problème. Si vous définissez les autorisations appropriées pour votre id_rsa via les paramètres de sécurité des explorateurs (il n'y a vraiment pas besoin d'y avoir d'autre utilisateur que le vôtre, pas "tout le monde", pas "administrateurs", pas "système". Aucun. Juste vous) , vous serez toujours en sécurité.

Maintenant, pourquoi mingw32, un système différent de celui Cygwin, ferait une utilisation de la variable d'environnement Cygwin, est au - delà de moi. Ça ressemble à un bug pour moi.


3
Cela n'a pas fonctionné pour moi. Je reçois toujours le message "FICHIER DE CLÉ PRIVÉE NON PROTÉGÉ". Je voulais juste vous faire savoir au cas où quelqu'un d'autre tomberait sur ce fil avec des résultats similaires.
Luc

A travaillé pour moi. C'est pourtant stupide. Je n'utilise même plus Cygwin. Aussi, comment diable avez-vous compris cela?
gamme

13

Je suis sous XP et cela a permis à Git Bash de communiquer avec Github (après beaucoup de frustration):

  1. copier c:\cygwin\bin\cyg*(~ 50 fichiers) versc:\Program Files\Git\bin\
  2. copier c:\cygwin\bin\ssh.exevers c:\Program Files\Git\bin\(écraser)
  3. Créez le fichier c:\Documents and Settings\<username>\.ssh\configcontenant:

    Host github.com
        User git
        Hostname github.com
        PreferredAuthentications publickey
        IdentityFile "/cygdrive/c/Documents and Settings/<username>/.ssh/id_rsa"
    
  4. (facultatif) Utilisez ssh -v git@githubpour voir la connexion déboguée.

  5. Essayez une poussée!

Contexte: Le problème général est une combinaison des deux:

  • BOGUE: mingw32 voit tous les fichiers comme 644 (autres / lisibles par groupe), et rien que j'ai essayé dans mingw32, cygwin ou Windows ne pouvait le corriger.
  • La version SSH de mingw32 ne permettra pas cela pour les clés privées (généralement une bonne politique dans un serveur).

Il ne sert à rien de créer un fichier c:\Documents and Settings\<username>\.ssh\configpuisque vous l'avez remplacé c:\Program Files\Git\bin\ssh.exe par c:\cygwin\bin\ssh.exe. Droite ?
爱国者

D'accord avec un commentaire "beaucoup de frustration". Pour gitolite, j'ai suivi ces étapes, en copiant cygwin / bin / cyg * dans mon répertoire Git (PortableGit - ou - Program Files / Git), et j'ai découvert que je pouvais alors utiliser git depuis Git-Bash, mais pas cygwin bash. L'ajout des répertoires bin PortableGit et Cygwin à mon PATH a également fonctionné avec un succès limité ... mais j'ai quand même dû déplacer PortableGit / bin / ssh.exe {,. Bak} afin qu'il ne soit pas utilisé accidentellement (même si c'est le même que c: /cygwin/bin/ssh.exe). Fondamentalement, ssh.exe doit être exécuté à partir du répertoire cygwin en raison d'autres dépendances qui n'ont pas été copiées.
Michael

Bien que cela fonctionne pour moi maintenant, la prochaine étape serait simplement d'ajouter à la fois Git et Cygwin au PATH, et de déplacer ssh.exe de Git de manière à ce que ssh.exe de cygwin soit utilisé (du répertoire bin de cygwin).
Michael

Ajoutez LogLevel DEBUGau fichier .ssh \ config pour obtenir la sortie de débogage du processus ssh.exe démarré par git.exe.
knb

Merci - cette solution a fonctionné pour moi! Plus précisément, à partir de c: \ cygwin \ bin \ j'ai copié ssh.exe, cygcrypto-0.9.8.dll, cygwin1.dll, cygminires.dll et cygz.dll vers C: \ Program Files \ Git \ bin \.
nexus-bytes

10

Pour Windows 7 utilisant le Git trouvé ici (il utilise MinGW, pas Cygwin):

  1. Dans l'explorateur Windows, cliquez avec le bouton droit sur votre fichier id_rsa et sélectionnez Propriétés
  2. Sélectionnez l'onglet Sécurité et cliquez sur Modifier ...
  3. Cochez la case Refuser à côté de Contrôle total pour tous les groupes SAUF Administrateurs
  4. Réessayez votre commande Git

1
C'était tout pour moi, mais maintenant j'ai un nouveau problème que ssh n'aime pas mon mot de passe, tout mot de passe que je donne à mon fichier de clés.
Jason Southwell

7

OK, voici comment j'ai forcé la modification de mes fichiers Windows concernant les autorisations elles-mêmes sur Win7: Trouvez votre clé ssh dans l'explorateur Windows: C: \ Users [your_user_name_here] .ssh \ id_rsa

Cliquez avec le bouton droit sur le fichier> Propriétés> onglet Sécurité> bouton Avancé> Modifier les autorisations

Supprimez maintenant tous ceux qui ne sont pas réellement votre nom d'utilisateur. Cela inclut l'administrateur et les utilisateurs du système. À ce stade, vous pouvez obtenir une boîte de dialogue sur l'héritage des autorisations - choisissez l'option qui N'HÉRITE PAS - car nous voulons uniquement modifier ce fichier.

Cliquez sur OK et enregistrez jusqu'à la fin.

Je me suis battu avec cela pendant des jours parce que mes fenêtres ne changeraient pas les autorisations de fichiers depuis la ligne de commande. De cette façon, cela est également EFFECTUÉ - au lieu d'utiliser des contournements passionnants qui peuvent avoir des conséquences étranges.


6

La modification des autorisations de fichier à partir des propriétés, la désactivation de l'héritage et l'exécution de chmod 400 n'ont pas fonctionné pour moi. Les autorisations pour mon fichier de clé privée étaient les suivantes:

-r - r ----- 1 alex Aucun 1766 8 mars 13:04 /home/alex/.ssh/id_rsa

Ensuite, j'ai remarqué que le groupe était None, alors j'ai juste couru

chown alex: Administrateurs ~ / .ssh / id_rsa

Ensuite, je pouvais changer avec succès les autorisations avec chmod 400 et exécuter un push git.


4

POUR LES UTILISATEURS MAC:

Modifiez les paramètres de votre fichier de paires de clés en tapant ceci dans le terminal:

chmod og-r *filename.pem*

(assurez-vous que vous êtes dans le bon répertoire ou chemin d'accès au nom de fichier dans la commande).




2

J'ai eu le même problème sur Windows XP récemment. J'ai essayé de chmod 700 sur mon fichier ~ / .ssh / id_rsa mais cela ne semblait pas fonctionner. Quand j'ai regardé les autorisations en utilisant ls -l sur le ~ / .ssh / id_rsa, j'ai pu voir que mes autorisations effectives étaient toujours 644.

Ensuite, je me suis souvenu que les autorisations Windows héritaient également des autorisations des dossiers, et le dossier était toujours ouvert à tout le monde. Une solution pourrait également être de définir des autorisations pour le dossier, mais je pense qu'une meilleure façon serait de dire au système d'ignorer l'héritage de 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 d'autres personnes ayant le même problème.


1

Je joue en ce moment 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 git@github.com: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 git@github.com
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 autorisations de fichier pour mes clés.

Environnement:

  • Windows Server 2008 SP2 sur NTFS
  • utilisateur: administrateur
  • environnement vars:
    • PLINK_PROTOCOL = ssh
    • ACCUEIL = / c / profiles / home

Mise à jour: Git 1.6.5.1 fonctionne également.


intéressant. On dirait que vous utilisez l'option mastic?
Ben Scheirman

1

Il s'agit d'un problème particulièrement complexe sous Windows, où il ne suffit pas de modifier correctement les fichiers. Vous devez configurer votre environnement.

Sous Windows, cela a fonctionné pour moi:

  1. Installez cygwin.

  2. Remplacez le msysgit ssh.exe par le ssh.exe de cygwin.

  3. En utilisant cygwin bash, chmod 600 le fichier de clé privée, qui était "id_rsa" pour moi.

  4. 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. Répétez ensuite l'étape 3.

    Valeur variable
    CYGWIN sbmntsec


1

J'ai pu résoudre ce problème en faisant deux choses, bien que vous n'ayez peut-être pas à effectuer l'étape 1.

  1. copier à partir de cygwin ssh.exe et tous les 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 réglé les choses)

  2. suivez les étapes depuis: http://zylstra.wordpress.com/2008/08/29/overcome-herokus-permission-denied-publickey-problem/

    J'ai ajouté quelques détails à mon fichier ~ / .ssh / config:

Hôte heroku.com
Nom d'hôte heroku.com
Port 22
IdentitiesOnly yes
IdentityFile ~ / .ssh / id_heroku
TCPKeepAlive yes
User brandon

J'ai dû utiliser l'utilisateur comme adresse e-mail pour heroku.com Remarque: cela signifie que vous devez créer une clé, je l'ai suivi pour créer la clé et quand il vous demande le nom de la clé, assurez-vous de spécifier id_heroku http: / /help.github.com/win-set-up-git/

  1. puis ajoutez la clé:
    clés heroku: ajoutez ~ / .ssh / id_heroku.pub

1

L'astuce pour moi a été de mettre à jour la variable d'environnement CYGWIN avec: " tty nodosfilewarning ". Je n'ai même pas eu besoin de modifier la clé.


0

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 vos "fichiers" sous l'équiv de c: \ cygwin \ home \ username. Il traite ce dossier pour tous les paramètres spécifiques à l'utilisateur plutôt que le répertoire utilisateur Windows.


0

À moins qu'il n'y ait une raison pour laquelle vous souhaitez conserver cette paire de clés privée / publique (id_rsa / id_rsa.pub), ou profiter de vous cogner la tête contre le mur, je vous recommande de les recréer et de mettre à jour votre clé publique sur github.

Commencez par faire une copie de sauvegarde de votre répertoire ~ / .ssh.

Saisissez ce qui suit et répondez "y" si vous souhaitez remplacer les fichiers existants.

ssh-keygen -t rsa

Copiez le contenu de la clé publique dans votre presse-papiers. (Voici comment vous devez le faire 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 obtenez des messages d'erreur insensés comme «Entrez votre mot de passe» pour votre clé publique lorsque vous n'en avez jamais entré, envisagez cette technique de redémarrage. Comme vous le voyez ci-dessus, ce n'est pas compliqué.


0

Je n'ai jamais réussi à faire fonctionner complètement Git à Powershell. Mais dans le shell git bash, je n'avais aucun problème lié aux autorisations, et je n'avais pas besoin de définir chmod etc ... Après avoir ajouté le ssh à Github, j'étais opérationnel.



0

Avez-vous copié le fichier clé d'une autre machine?

Je viens de créer un id_rsafichier sur la machine cliente puis de coller la clé que je voulais. Aucun problème d'autorisations. Rien à régler. Ça 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 une autre machine.

Testé sur deux machines Windows 8.1. Utilisation de Sublime Text 3 pour copier et coller la clé privée. Utilisation de Git Bash (Git-1.9.4-preview20140611).


0

Après avoir mis à niveau 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' UNPROTECTED PRIVATE KEY FILEavertissement.

J'ai résolu ce problème après avoir exécuté la commande suivante:

setfacl -s u::rw-,g::---,o:--- ~/.ssh/id_rsa

( une autre réponse à une autre question donne plus de contexte)


0

La réponse de @ koby ne fonctionne pas pour moi, je fais donc un petit changement.

cd ~/.ssh
chmod 700 id_rsa.pub

Cela fonctionne bien pour moi sur Mac.


0

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:

  1. Installez la dernière version d'OpenSSH depuis http://www.mls-software.com/opensshd.html
  2. where.exe ssh

(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 deuxième dans le chemin, il ne s'exécutera donc pas.

Pour modifier la commande:

  1. Cliquez avec le bouton droit sur le bouton Windows -> Paramètres -> "Modifier les variables d'environnement système"
  2. Dans l'onglet "Avancé", cliquez sur "Variables d'environnement ..."
  3. Sous Variables système, modifiez "Chemin".
  4. Sélectionnez "C: \ Program Files \ OpenSSH \ bin" et "Déplacer vers le haut" pour qu'il apparaisse en haut.
  5. Cliquez sur OK
  6. Redémarrez votre console pour que les nouvelles variables d'environnement s'appliquent.

0

Mon système est un peu en désordre avec bash / cygwin / git / msysgit / peut-être plus ...

chmodn'a eu aucun effet sur la clé ou le configfichier.

J'ai alors décidé de l'aborder depuis Windows, ce qui fonctionnait.

  1. Cliquez avec le bouton droit sur le fichier dont l'autorisation doit être corrigée.
  2. Sélectionnez Properties.
  3. Sélectionnez l' Securityonglet.
  4. Cliquez Advancedprès du bas.
  5. Cliquez sur Change, près de Ownerprès du haut.
  6. Tapez « My-Impressionnant-Nom d' utilisateur » (évidemment changer que votre nom d' utilisateur Windows), puis cliquez sur Check Names, puis OK.
  7. Sous 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 que "My-Awesome-Username" soit le seul qui reste.
  8. Sélectionnez "My-Awesome-Username" et cliquez Editci-dessous.
  9. Assurez-vous que Type:la partie supérieure est définie sur Allow, puis cochez la case en regard de Full control.
  10. Hit OK, Apply, OK, OK.

  11. Essayez-le maintenant ...

Il semble que parfois le mock-bash ne puisse pas contrôler la propriété du fichier. C'est particulièrement bizarre, car il est généré à partir d'un script mock-bash. Allez comprendre.


0

Aucune des solutions de contournement suggérées ici (perms chmod / chgrp / setfacl / windows) n'a fonctionné pour moi avec msys64 sur une machine virtuelle d'entreprise Windows 7. Finalement, j'ai contourné le problème en utilisant un agent ssh avec la clé fournie sur stdin. L'ajout de cela à mon en .bash_profilefait la valeur par défaut pour ma connexion:

eval $(ssh-agent -s)
cat ~/.ssh/id_rsa | ssh-add -k -

Maintenant, je peux faire git push and pull avec des télécommandes ssh.

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.