Ma configuration de Git fonctionne bien sous Linux, mais lorsque j'essaie de configurer les choses sous Windows (en utilisant Git for Windows et TortoiseGit ), je ne sais pas où mettre ma clé privée SSH (ou, mieux encore, comment dire à ssh où il se trouve). J'utilise l'option standard ssh.exe lors de l'installation de Git pour Windows. La configuration fonctionne bien si j'autorise l'authentification par mot de passe (au lieu de RSA) sur le serveur.
J'ai eu des problèmes similaires et aucune des réponses données ici n'a résolu le problème. Il s'avère que ma paire de clés a été générée à l'origine avec une phrase de passe vide. (Je sais, idiot.)
Une fois que j'ai créé une nouvelle paire de clés et téléchargé la clé publique sur GitHub, les choses ont recommencé à fonctionner.
Lorsque vous mélangez GitHub pour Windows et Git GUI pour Windows, vous pouvez rencontrer des problèmes lorsque Git GUI vous demande sans cesse un nom d'utilisateur et un mot de passe. Le remède à ce problème est de changer l'URL distante de https: (ce que crée GitHub pour Windows) au protocole Git. Dans le .git dans le fichier de configuration, trouver :
[remote "origin"]
url = https://github.com/**username**/**reponame**.git
fetch = +refs/heads/*:refs/remotes/origin/*Changez-le en :
[remote "origin"]
url = git@github.com:**username**/**reponame**.git
fetch = +refs/heads/*:refs/remotes/origin/*
Oui, c'est très ennuyeux. Il est naturel et facile de cloner un repo avec l'interface graphique de github pour Windows, mais quand on utilise git cui en dehors de git Shell échoue. Je me demande comment la commande git dans le Shell fonctionne avec une url https....
L'emplacement standard des fichiers se trouve dans %USERPROFILE%\.ssh .
%USERPROFILE% est l'équivalent de $HOME sous Unix (il correspond normalement à quelque chose comme c:\users\youruserid ).
Si vous utilisez les outils SSH fournis avec Git, qui sont les outils standards de type Unix en ligne de commande, vous pouvez utiliser quelque chose comme mon script ici pour travailler avec ssh-agent sur tous les shells.
Pour les futurs lecteurs, %USERPROFILE% is the equivalent of $HOME es no l'équivalent de $HOME . Beaucoup d'applications Linux de mauvais goût portées sur Windows traitent les deux de la même manière, alors qu'elles devraient le faire. no être traitées de la même manière.
Micah, pouvez-vous informer les différences d'intention pour cela ? De plus, même avec des intentions différentes, il semblerait que si tous les outils utilisent l'un comme l'autre, alors ne deviennent-ils pas effectivement équivalents ?
Les outils qui utilisent %USERPROFILE% sur Windows de la même manière que $HOME sur Linux violent les meilleures pratiques/recommandations bien documentées pour le développement de Windows (publiées par MS il y a longtemps et mises à jour au fil du temps). Il existe de nombreux outils qui font cela, mais l'argument pour les suivre ressemble beaucoup à l'argument "X pisse dans la piscine, donc nous devrions aussi". USERPROFILE est l'endroit où l'utilisateur stocke les documents ils créer/sauvegarder (par exemple, dialogue de sauvegarde). APPDATA est pour les données de configuration par utilisateur. LOCALAPPDATA est pour les caches par utilisateur et les gros fichiers. PROGRAMDATA est destiné à la configuration et au cache de la machine.
OK, j'ai regardé la suggestion de . .
Mais placer mes clés SSH privées dans un dossier public ne me semblait pas être une bonne idée, alors j'ai commencé à chercher où se trouvait le knownhost.
Donc, si vous voulez protéger correctement votre clé SSH, vous devez placer votre clé dans le répertoire suivant :
Pour Windows 7, 8 et 8.1 32 bits :
C:\Users\\AppData\Local\VirtualStore\Program Fichiers \Git\
Pour Windows 7, 8 et 8.1 64 bits :
C:\Users\\AppData\Local\VirtualStore\Program Fichiers (x86) \Git\
C'était la solution la plus simple sur ma machine Win7. Comme vous, j'ai cherché known_hosts . Bien sûr, c'était dans C:\Users\Dave\AppData\Local\VirtualStore\Program Files (x86)\Git\.ssh . En plaçant mon fichier de clé (id_rsa) dans ce répertoire, ssh a pu le trouver sans problème. J'ai lu un peu - c'est ainsi que Windows traite les logiciels (anciens) qui tentent d'écrire dans des zones interdites (comme " C:\Program Files\"), ainsi le ssh de Git n'est absolument pas conscient qu'il écrit dans le répertoire VirtualStore, Windows gère cela de manière transparente. Au moins, ces fichiers appartiennent à un utilisateur !
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
0 votes
J'ai le même problème, je peux me connecter à ma boîte de développement en utilisant une clé publique en tant que "root" en utilisant le programme "Git Bash" qui est installé avec "Git For Windows" mais je ne peux pas me connecter en tant que "git" avec ma clé même si j'ai copié mon fichier "authorized_keys" de mon "root" vers mon utilisateur "git" et que j'ai défini les propriétaires et les permissions correctement. Pourquoi ne puis-je pas me connecter en tant que "git" alors que "root" fonctionne avec exactement le même fichier "authorized_keys". Au lieu de cela, pour "git", il transmet toutes les clés privées, qui sont exactement les mêmes que celles qui fonctionnent avec "root" et demande un mot de passe. Au fait, il s'agit d'un serveur Centos 5.5.
0 votes
@fuzzy lollipop : Avez-vous les bonnes permissions sur le fichier authorized_keys de votre utilisateur git ? Il devrait être chmod 600, et devrait appartenir à l'utilisateur git. S'il appartient à l'utilisateur root, cela ne fonctionnera pas.
0 votes
Oui tous les fichiers et répertoires ont les propriétaires et les permissions corrects