Clé SSH - Toujours demander un mot de passe et une phrase secrète

496

J'ai un peu «supporté» que Github me demande toujours mon nom d'utilisateur et mon mot de passe lorsque je clone un référentiel. Je veux contourner cette étape car c'est une gêne dans mon flux de travail.

J'ai essayé de configurer une clé SSH (ce que j'ai réussi) en utilisant ce guide. https://help.github.com/articles/generating-ssh-keys et j'ai réussi.

Mon problème est que l'on me demande toujours mon mot de passe github et ma phrase secrète lors du clonage d'un référentiel (en utilisant SSH). J'ai cru comprendre qu'après avoir configuré cette clé SSH, je n'aurais plus à le faire.

Je ne sais pas trop quoi demander, alors je vais simplement énoncer mon objectif.

Je veux pouvoir cloner des référentiels sans avoir à mettre mes informations Github tout le temps .

Que manque-t-il avec ma clé SSH? Si quelqu'un peut fournir des conseils ou des ressources, je l'apprécierais, car je me suis toujours senti un peu perdu en matière d'authentification SSH dans GitHub.

D'après mes connaissances, il s'agit d'une commande qui teste si les choses fonctionnent correctement, voici la sortie de ma console:

~ $ ssh -T [email protected]
Saving password to keychain failed
Enter passphrase for key '/Users/MYNAME/.ssh/id_rsa':
Hi MYNAME! You've successfully authenticated, but GitHub does not provide shell access.

Lorsque j'entre mon mot de passe, cela devrait-il échouer en premier? Ensuite, lorsque j'entre ma phrase secrète, elle passe.

Bonjour le monde
la source
1
Dans quel OS êtes-vous? Un bureau Linux moderne proposerait de stocker votre phrase secrète dans un gestionnaire de porte-clés. Même chose sous Mac OS X. Dans Windows, vous pouvez utiliser pageant, qui fait partie de putty. Dans tous ces cas, l'objectif est le même: vous entrez la phrase secrète une seule fois après avoir démarré votre PC, les agents du gestionnaire de clés le transmettront à ssh lors des utilisations suivantes jusqu'à ce que vous redémarriez.
janos
2
Je suis un peu en retard pour la fête ici, mais sur le petit onglet / bouton clone dans github, il y a un lien qui dit "Utiliser SSH". Tu veux faire ça. Il change votre lien de clone en quelque chose comme "git @ github: username / project.git". Si vous avez ajouté une clé SSH à github et l'avez exécutée localement sur ssh-agent, vous devriez pouvoir pousser sans entrer de nom d'utilisateur ou de mot de passe.
Logan Kitchen du

Réponses:

201

Si vous travaillez avec des HTTPsURL, il vous demandera toujours votre nom d'utilisateur / mot de passe.

Si vous utilisez correctement SSHlors du clonage / réglage des télécommandes. Assurez-vous ensuite que vous disposez d'un agent ssh pour mémoriser votre mot de passe. De cette façon, vous n'entrerez votre mot de passe qu'une seule fois par session de terminal.

Si cela est toujours trop ennuyeux, définissez simplement une clé ssh sans mot de passe.

Simon Boudrias
la source
2
Merci pour la réponse. J'ai toujours utilisé des HTTPs. J'essaie d'obtenir l'authentification SSH et j'ai pensé que je l'ai configurée. L'agent ssh est-il quelque chose en dehors de git que je dois installer? Merci
HelloWorld
1
@ R11G vous ne pouvez pas, sinon les mots de passe ne seraient pas sécurisés ... Il suffit de régénérer un nouveau.
Simon Boudrias
50
Je veux juste noter que les mots de passe sont utilisés pour crypter votre clé privée, donc si vous n'utilisez pas de phrase secrète, votre clé privée ne sera pas cryptée sur votre machine. C'est comme laisser un mot de passe dans un fichier texte qui traîne sur votre ordinateur.
2
Drôle, mes repos HTTPS ne demandent jamais de mots de passe et mes repos SSH le font toujours.
Adam
33
Voir ce doc github pour convertir l'URL de la télécommande de https en ssh. Pour vérifier si l'URL de la télécommande est ssh ou https, utilisez git remote -v. Pour passer de https à ssh:git remote set-url origin [email protected]:USERNAME/REPOSITORY.git
Manavalan Gajapathy
826

Ajouter une identité sans trousseau

Il peut arriver que vous ne souhaitiez pas que la phrase secrète soit stockée dans le trousseau, mais que vous ne souhaitiez pas avoir à saisir la phrase secrète encore et encore.

Vous pouvez faire ça comme ceci:

ssh-add ~/.ssh/id_rsa 

Cela vous demandera le mot de passe, entrez-le et il ne vous le demandera pas avant de redémarrer.

Ajouter une identité à l'aide du trousseau

Comme le souligne @dennis dans les commentaires, pour conserver la phrase secrète lors des redémarrages en la stockant dans votre trousseau, vous pouvez utiliser l' -Koption ( -kpour Ubuntu) lors de l'ajout de l'identité comme ceci:

ssh-add -K ~/.ssh/id_rsa

Encore une fois, cela vous demandera la phrase secrète, entrez-la et cette fois, elle ne demandera plus jamais cette identité.

Komu
la source
178
Notez que cela ne persistera pas l'identité au redémarrage. Vous pouvez utiliser l' -Koption pour stocker la phrase secrète dans votre trousseau lors de l'ajout, par exemplessh-add -K ~/.ssh/id_rsa
Dennis
29
minuscules -kpour moi ... (Linux Mint / Ubuntu 14.04 base) mais oui! enfin trié cela ...
Louis Maddox
8
exécutez simplement la commande "ssh-add" et entrez le mot de passe une fois, la ligne de commande ne vous demandera plus de saisir le mot de passe.
AVINASH SHRIMALI
14
Vous n'avez besoin d'aucun argument; juste en cours d'exécution ssh-addajoutera automatiquement ~/.ssh/id_rsa(parmi d'autres fichiers). Et il n'y a aucune raison d'envoyer la sortie à /dev/null; beaucoup mieux pour voir le rapport de ce qu'il a fait.
Ted Hopp
6
Une idée pourquoi je reçois "Impossible d'ouvrir une connexion avec votre agent d'authentification."?
dokaspar
252

Sur Mac OSX, vous pouvez ajouter votre clé privée au trousseau en utilisant la commande:

ssh-add -K /path/to/private_key

Si votre clé privée est stockée dans ~ / .ssh et s'appelle id_rsa:

ssh-add -K ~/.ssh/id_rsa

Vous serez ensuite invité à entrer votre mot de passe, qui sera stocké dans votre trousseau.

Modifier - Gérer le redémarrage

Afin de ne pas avoir à saisir votre mot de passe même après un redémarrage, ajoutez ce qui suit à votre fichier de configuration ssh (généralement situé à ~ / .ssh / config)

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa
Groot
la source
7
Dans mon cas, il demande toujours la phrase secrète après le redémarrage (macOS Sierrra 10.12.2). Des idées sur la façon de résoudre ce problème?
inigo333
9
Peu importe, je viens de trouver le problème. Il s'agit d'un bogue (fonctionnalité?) De Mac OS X 10.12 dans lequel l'agent ssh ne charge pas automatiquement les phrases secrètes sur le trousseau lors du démarrage. github.com/lionheart/openradar-mirror/issues/15361
inigo333
2
@ inigo333 intéressant. Je viens de mettre à jour et j'ai remarqué cela moi-même!
Groot
1
@Groot, BTW, l'ajout de "Host * UseKeychain yes" à "~ / .ssh / config", comme suggéré dans d'autres réponses, résout le problème.
inigo333
1
Ce devrait être la réponse acceptée. Surtout le fichier de configuration dans~/.ssh
Xavi
186

J'ai essayé toutes les réponses ici et aucune de ces réponses n'a fonctionné ! Mon mot de passe ne persisterait pas entre les sessions / redémarrages de mon Mac.

Ce que j'ai découvert en lisant cet OpenRadar et cette discussion sur Twitter, c'est qu'Apple a délibérément changé le comportement de ssh-agent dans macOS 10.12 Sierra pour ne plus charger automatiquement les précédentes clés SSH. Afin de maintenir le même comportement qu'El Cap, j'ai fait ce qui suit:

  1. ssh-add -K ~/.ssh/id_rsa
    Remarque: modifiez le chemin d'accès à l'emplacement de votre clé id_rsa.
  2. ssh-add -A
  3. Créez (ou modifiez s'il existe) le ~/.ssh/configfichier suivant :

    Host *
      UseKeychain yes
      AddKeysToAgent yes
      IdentityFile ~/.ssh/id_rsa
    

Et maintenant mon mot de passe est mémorisé entre les redémarrages de mon Mac!

ChrisJF
la source
2
Cela peut être utile à ajouter aux pages de documentation github ou osx . J'ai eu le plus de mal à comprendre pourquoi mon Mac exécutant 10.11 et mes autres exécutant 10.12 se comportaient différemment.
Grr
5
Cela m'est arrivé après une mise à niveau OSX, merci (je pense que ce ssh-add -An'est pas nécessaire si vous n'avez qu'une seule clé ~/.ssh/id_rsa)
Dorian
1
Ceci est une réponse incroyablement utile. Merci, tu as fait ma journée.
Jan Nash
2
Depuis octobre 2017, cette réponse est exactement ce que vous recherchez si vous utilisez macOS 10.12 ou supérieur.
brogrammer
3
Et ceci est maintenant sur les documents github: help.github.com/articles/…
Todd Price
35

Vous pouvez supprimer la phrase secrète de la clé

$ ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

ou vous pouvez courir

$ ssh-keygen -p

vous obtenez une invite pour le fichier de clés. Par défaut ~/.ssh/id_rsa, appuyez sur Entrée

Vous serez invité à saisir la phrase de passe actuelle.

Ensuite, il y aura une invite pour une nouvelle phrase de passe, appuyez sur Entrée

sudo bangbang
la source
Cela devrait être supérieur à beaucoup de réponses presque identiques pour ajouter la phrase secrète au trousseau. J'ai dû donner ma clé publique à un administrateur et y inclure une phrase secrète qui devenait ennuyeuse à taper à chaque fois. Ceci est une solution propre quand vous n'avez pas beaucoup de contrôle sur votre machine ( -K, -k, -Ane fonctionne pas pour moi).
gwg
1
C'est la seule chose qui a fonctionné pour moi à travers les redémarrages, toutes les commandes ssh-add -K, -k, etc. n'ont rien fait pour moi.
Amalgovinus
28

Exécutez simplement la commande suivante:

ssh-add -K

Il ne vous demandera plus jamais d'entrer à nouveau le mot de passe.

user3640130
la source
3
Cela fonctionne très bien, mais j'étais un peu préoccupé par l'exécution d'une commande aléatoire. Cependant, si vous vérifiez les documents ssh-addjuste "ajoute des identités de clé privée à l'agent d'authentification", et l' -Koption le rend simplement "Lors de l'ajout d'identités, chaque phrase secrète sera également stockée dans le trousseau de l'utilisateur."
machineghost
8
En fait, il ne l'a corrigé que lorsque j'ai redémarré :(
machineghost
5
dans le shell bash pour Windows, l'indicateur "-k" doit être en minuscules. Just FYI
Fergus
27

Assurez-vous que vous utilisez également ssh pour votre référentiel

mahtab@mahtab-Lenovo-G50-70:~/my-projects/jenkins-cje-2017$ git remote -v origin [email protected]:eMahtab/jenkins-cje-2017.git (fetch) origin [email protected]:eMahtab/jenkins-cje-2017.git (push)

entrez la description de l'image ici

N'utilisez pas https, si votre télécommande utilise https, elle continuera à demander un mot de passe, même si vous avez ajouté la clé publique à Github et ajouté la clé privée à ssh-agent. Ci-dessous vous demandera toujours un mot de passe

mahtab@mahtab-Lenovo-G50-70:~/my-projects/jenkins-cje-2017$ git remote -v origin https://github.com/eMahtab/jenkins-cje-2017.git (fetch) origin https://github.com/eMahtab/jenkins-cje-2017.git (push)

Mahtab Alam
la source
Oui, la distinction entre les deux types d'URL distants m'a été utile. Cela m'a aidé en termes de git pullet git push. J'ai changé mon URL du type HTTPS au type SSH, et cela a fonctionné - j'ai git pullcessé de demander un mot de passe.
Michael R
1
La commutation peut être effectuée avec cette commande:git remote set-url origin [email protected]:USERNAME/REPOSITORY.git
guido
17

J'ai dû exécuter:

eval `ssh-agent -s`
ssh-add

Remarque : vous devrez recommencer après chaque redémarrage. Si vous voulez l'éviter, entrez-le dans votre fichier " .bashrc " qui se trouve sous C:\Users\<<USERNAME>>\.bashrcWindows. Il est probablement caché, alors assurez-vous que vous pouvez voir les fichiers cachés.

Solution trouvée ici .

Noir
la source
15

Si vous utilisez Windows, cela a fonctionné pour moi:

eval `ssh-agent -s`
ssh-add ~/.ssh/*_rsa

Il vous demandera une phrase secrète dans la deuxième commande, et c'est tout.

Marina
la source
1
Lorsque vous vous déconnectez et vous reconnectez, vous devez saisir à nouveau le mot de passe à chaque fois.
trainoasis
12

TL; DR
Vous devez utiliser un agent ssh. Alors, ouvrez le terminal et essayez

ssh-add

avant de pousser à git. Entrez votre phrase secrète lorsque vous y êtes invité.

Découvrez la réponse originale de StackExchange ici

Junaid
la source
6

J'ai récemment mis à niveau vers macOS Mojave, et installé certains outils via homebrew, qui semblait remplacer la version d'Apple ssh-addpar une autre. Ma version par défaut de ssh-add n'avait pas l' -Koption. Cela a conduit à l'erreur suivante:

# ssh-add: illegal option -- K

Vous pouvez voir quelle version de ssh-addvous avez en exécutantwhich ssh-add .

(Le mien était entreposé /usr/local/bin/ssh-add)

Pour résoudre ce problème, j'ai dû pointer la clé de la version d'Apple :

/usr/bin/ssh-add -K ~/.ssh/id_rsa

Git / GitHub a parfaitement fonctionné par la suite. Pour plus d'informations, voir: Erreur: ssh-add: option illégale - K

aboutaaron
la source
J'ai eu le même problème sur mon iMac avec High Sierra 10.13.6 - cela a fonctionné pour moi. Merci!
emccracken
La mienne fonctionnait bien et a recommencé au hasard à demander des phrases secrètes - peut-être après une récente mise à jour. Cela l'a corrigé! Merci
mc01
5

Pour Mac OSX Sierra, j'ai trouvé que les correctifs suggérés dans le problème github pour Open Radar ont résolu mon problème. On dirait que Sierra a changé le comportement par défaut (j'ai commencé à avoir ce problème après la mise à niveau).

Celui-ci je l'ai trouvé particulièrement utile: https://github.com/lionheart/openradar-mirror/issues/15361#issuecomment-249059061

ssh-add -A 

Cela a abouti à mon identité ajoutée à l'agent, après avoir couru

ssh-add -K {/path/to/key}

Pour résumer, dans OSX.12:

ssh-add -K {/path/to/key}
ssh-add -A 

devrait se traduire par:

Identity added: {/path/to/file} ({/path/to/file})

EDIT: J'ai remarqué que la prochaine fois que je faisais un redémarrage complet (alias l'agent s'est arrêté et redémarré), cela ne fonctionnait plus. La solution la plus complète est ce que @ChrisJF a mentionné ci-dessus: créer un ~/.ssh/configfichier. Voici ma sortie:

$ cat ~/.ssh/config
Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa

Vous pouvez ajouter autant d' IdentityFileentrées que vous le souhaitez, mais il s'agit de la configuration par défaut. C'est la réponse "tendance" sur le lien openradar ci-dessus, ATM également.

zedd45
la source
Celui édité a résolu mon problème. MacOS Mojave 10.14.3
Jose
4

Travaillé dans LinuxMint / Ubuntu

Effectuez les étapes suivantes

Étape 1:

Aller au fichier => /.ssh/config

Enregistrez les lignes ci-dessous dans le fichier

Host bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /home/apple/myssh-privatekey
    AddKeysToAgent yes

N'oubliez pas d'ajouter cette ligne AddKeysToAgent oui

Étape 2:

Ouvrez le terminal et ajoutez le jeu de clés à ssh-add

$ ssh-add -k /home/apple/myssh-privatekey

fournir la phrase secrète.

DhineshOui
la source
3

J'avais déjà défini un mot de passe, mais pour une raison quelconque, il ne le reconnaîtrait plus. J'ai donc ajouté à nouveau le fichier d'identité à mon trousseau ssh-add -Ket il a cessé de demander mon mot de passe.

André Herculano
la source
cela ne charge que les clés et non les certificats
numediaweb
3

C'est ce qui a fonctionné pour moi:

git config --global core.sshCommand "'C:\Windows\System32\OpenSSH\ssh.exe'"
daniel sp
la source
2

Le problème semble être dû au fait que vous clonez à partir de HTTPS et non de SSH. J'ai essayé toutes les autres solutions ici, mais je rencontrais toujours des problèmes. Cela l'a fait pour moi.

En utilisant osxkeychain helperainsi:

  1. Découvrez si vous l'avez installé.

    git credential-osxkeychain

  2. S'il n'est pas installé, vous serez invité à le télécharger dans le cadre des outils de ligne de commande Xcode.

  3. S'il est installé, indiquez à Git d'utiliser osxkeychain helperla credential.helperconfiguration globale :

    git config --global credential.helper osxkeychain

La prochaine fois que vous clonerez une URL HTTPS, vous serez invité à saisir le nom d'utilisateur / mot de passe et à autoriser l'accès au trousseau OSX. Après avoir fait cela la première fois, il devrait être enregistré dans votre trousseau et vous n'aurez pas à le saisir à nouveau.

Bryan Perez
la source
2

Cette réponse s'adresse principalement aux utilisateurs de Windows et est également pertinente si vous rencontrez des problèmes de clonage avec tfs, github ou gitlab sur un autre système d'exploitation.

Le mode d'authentification par défaut lors de l'utilisation de SSH est la clé privée. Chaque fois que cela échoue pour une raison quelconque, l'agent ssh revient à l'authentification basée sur le nom d'utilisateur et le mot de passe.

Il y a plusieurs raisons pour lesquelles l'authentification par clé basée par défaut peut avoir échoué. Voici les cas les plus courants:

a) L'agent ssh ne peut pas trouver le fichier de clé privée par défaut qui est id_rsa , et aucun autre chemin de clé n'est spécifié explicitement.

b) La clé publique stockée sur le serveur est incorrecte.

c) Le chemin que vous essayez de cloner est incorrect.

Dans tous les cas, pour résoudre le problème, exécutez d'abord la commande git clone avec une journalisation détaillée avec la commande:

GIT_TRACE=1 GIT_SSH_COMMAND="ssh -vvv" git clone ssh://pathToYourRepo

Vous pouvez parcourir chaque étape du journal pour obtenir une intuition de ce que pourrait être le problème.


Dépannage en cas de (a)

  • Assurez-vous que le nom de clé par défaut id_rsa se trouve dans le répertoire .ssh. Vous avez peut-être spécifié un nom de clé différent lors de la génération de la clé avec la commande ssh-keygen ou il n'y a peut-être pas de clé du tout).
  • Si vous souhaitez spécifier une clé différente pour l'authentification, utilisez la commande suivante:

    ssh-agent bash -c 'ssh-add ~/.ssh/anotherKey; git clone ssh://pathToYourRepo'
    

Dépannage en cas de (b)

  • Assurez-vous qu'il n'y a pas d'espaces blancs supplémentaires lors du stockage de la clé publique sur le serveur.

Dépannage en cas de (c)

  • Assurez-vous que vous n'essayez pas de cloner avec la version https du chemin du référentiel.
chaosifier
la source
1

Si vous utilisez l'URL ssh pour git, lorsque vous êtes invité à entrer le mot de passe pour ssh, entrez le nom d'utilisateur comme " git " et le mot de passe comme mot de passe de connexion de votre système

Vinayak Deshpande
la source
Modification du type d'URL distante du référentiel de HTTPSàSSH résolu mon problème. Merci @MichaelR, votre article a été très utile, même si je n'en ai rien lu: D
Geradlus_RU
1

Je voudrais ajouter une réponse pour ceux qui peuvent encore avoir besoin d'entrer le mot de passe car ils ont défini IdentitiesOnly comme oui. Cela peut être dû à plusieurs clés et au fichier d'identité, étant des clés pour git ou serveur.

Après avoir généré la clé et l'avoir copiée sur le serveur:

ssh-keygen
ssh-copy-id -i ~/.ssh/12gpu_server.pub [email protected]

J'ai trouvé que ça ne marchait pas.

Ensuite, je suis allé vérifier le ~/.ssh/configdossier, je l'ai vu en bas:

Host *
IdentitiesOnly yes

Ensuite, j'ajoute ceci ci-dessus:

Host 12gpu
HostName 192.168.20.160
User lerner
IdentityFile ~/.ssh/12gpu_server

Je peux simplement me connecter en entrant ssh 12gpu.

Ensuite, vous pouvez ajouter plusieurs clés ssh en utilisant vos noms préférés, et vous n'avez qu'à ajouter les paramètres tels que les quatre lignes ci-dessus au fichier de configuration.

Hôte est le nom que vous souhaitez saisir lorsque vous vous connecterez au serveur ultérieurement; le HostName est l'IP ou le domaine du serveur comme github.com; Utilisateur est le nom d'utilisateur que vous vous connectez au serveur, comme le nom d'utilisateur ou git pour github ou gitlab; et IdentityFile est le fichier dans lequel vous stockez la clé que vous avez générée.

Lerner Zhang
la source
1

Généralement, voici les étapes pour vous permettre de vous connecter à distance à votre serveur en utilisant ssh sans mot de passe:

  • Créer une paire de clés privée et publique rsa

    $ ssh-keygen -t rsa -b 4096 -C "your comments"
    
  • Copiez votre clé publique et connectez-vous à votre serveur distant

  • Ajoutez votre clé publique à .ssh / authorized_keys

  • Si vous avez plusieurs clés ssh sur votre ordinateur, vous pouvez ajouter votre clé à l'aide de ssh-add

    $ ssh-add /path/to/private/key

  • Essayez ensuite ssh sur votre serveur

    $ ssh username@your_ip_address

Source: http://diary-of-programmer.blogspot.com/2018/08/tips-how-to-ssh-to-your-digitalocean.html

Anang Satria
la source
0

N'utilisez pas sshl'url distante fournie par Github https.

Lost Koder
la source
L'OP a clairement dit qu'il utilisait SSH au lieu de HTTPS.
lent
0

Si vous utilisez Windows et GIT sans outils tiers et que votre clé n'est pas sécurisée par un mot de passe / phrase de passe, utilisez ceci:

  1. La variable d'environnement HOME doit être définie sur votre profil utilisateur (par exemple, C: \ Users \ Laptop)
  2. Accédez au dossier C: \ Users \ Laptop \ .ssh \ et éditez le fichier "config" (ou créez le fichier!) Exemple: C: \ Users \ Laptop.ssh ​​\ config (remarque: il n'y en a pas à la fin!)
  3. Ajoutez votre hôte git-server au fichier "config" comme ceci:

    #Example host entry
    Host myhostname.com
        HostName myhostname.com
        User git
        IdentityFile c:/users/laptop/.ssh/id_rsa.pub
        PasswordAuthentication no
        Port 422
    
  4. Enregistrez le fichier et clonez le référentiel comme ceci:

    git clone ssh: //myhostname.com/git-server/repos/picalc.git

Vous pouvez utiliser des paramètres de configuration supplémentaires pour l'entrée d'hôte de fichier "config". Ceux-ci peuvent être trouvés dans votre dossier d'installation git local, par exemple " C: \ Program Files \ Git \ etc \ ssh \ ssh_config ". Extrait:

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Protocol 2
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
Fabian Stern
la source
0

Même problème pour moi et la solution était:

Voir ce doc github pour convertir l'URL de la télécommande de https en ssh. Pour vérifier si l'URL de remote est ssh ou https, utilisez git remote -v. Pour passer de https à ssh: git remote set-url origin [email protected]: USERNAME / REPOSITORY.git @jeeYem

Bruno Leite
la source
0

Mobaxterme avait une interface UI pour cela

setting > configuration > SSH > SSH Agent > [check] Use internal SSH agent "moboAgent" > add [your id_rsa and restart mobaxterme to set changes]

Amir Heshmati
la source
0

Clé SSH - Toujours demander un mot de passe et une phrase secrète

Si sur Windows et en utilisant PuTTY comme générateur de clé SSH , cette solution rapide et facile s'est avérée être la seule solution de travail pour moi en utilisant une ligne de commande Windows simple:

  1. Votre installation PuTTY devrait être accompagnée de plusieurs exécutables, entre autres, pageant.exeetplink.exe
  2. Lors de la génération d'une clé SSH avec PuttyGen, la clé est stockée avec l' .ppkextension
  3. Exécuter "full\path\to\your\pageant.exe" "full\path\to\your\key.ppk"( doit être indiqué). Cela exécutera le pageantservice et enregistrera votre clé (après avoir entré le mot de passe).
  4. Définissez la variable d'environnement GIT_SSH=full\path\to\plink.exe( ne doit pas être indiquée entre guillemets). Cela redirigera les commandes liées à git ssh-communication vers plinkcelles qui utiliseront le pageantservice pour l'authentification sans demander à nouveau le mot de passe.

Terminé!

Remarque 1: cette documentation met en garde contre certaines particularités lors de l'utilisation GIT_SHHdes paramètres de variable d'environnement. Je peux push, pull, fetchavec un certain nombre de paramètres supplémentaires à la commande et tout fonctionne très bien pour moi (sans qu'il soit nécessaire d'écrire un script supplémentaire tel que suggéré dans celui - ci).

Remarque 2: Le chemin vers l' PuTTYinstalation est généralement dans PATHainsi peut être omis. Quoi qu'il en soit, je préfère spécifier les chemins complets.

Automatisation:

Le fichier de commandes suivant peut être exécuté avant d'utiliser git à partir de la ligne de commande. Il illustre l'utilisation des paramètres:

git-init.bat
   @ECHO OFF
   :: Use start since the call is blocking
   START "%ProgramFiles%\PuTTY\pageant.exe" "%HOMEDRIVE%%HOMEPATH%\.ssh\id_ed00000.ppk"
   SET GIT_SSH=%ProgramFiles%\PuTTY\plink.exe

Quoi qu'il en soit, j'ai la GIT_SSHvariable définie SystemPropertiesAdvanced.exe > Environment variableset pageant.exeajoutée commeRun clé de registre (*).

(*) Étapes pour ajouter une Runclé de registre>

  1. courir regedit.exe
  2. Aller vers HKEY_CURRENT_USER > Software > Microsoft > Windows > CurrentVersion > Run
  3. Faire (menu) Edit > New > String Value
  4. Entrez un nom arbitraire (mais unique)
  5. Faire (menu) Edit > Modify...(ou double-cliquer)
  6. Entrez le chemin entre guillemets pageant.exeet public key, par exemple, "C:\Program Files\PuTTY\pageant.exe" "C:\Users\username\.ssh\id_ed00000.ppk"(notez que les %ProgramFiles%variables etc. ne fonctionnent pas ici sauf si vous choisissez Expandable string valueà la place de l' String valueétape 3.).
PavDub
la source
-1

Je pense que la réponse de @sudo bangbang devrait être acceptée.

Lorsque vous générez la clé ssh, vous appuyez simplement sur "Entrée" pour ignorer la saisie de votre mot de passe lorsqu'il vous invite à configurer le mot de passe.

Cela signifie que vous N'AVEZ PAS BESOIN d'un mot de passe lorsque vous utilisez la clé ssh, alors souvenez-vous lorsque vous générez une clé ssh, N'entrez PAS de mot de passe, appuyez simplement sur 'Entrée' pour l'ignorer.

andrava
la source
1
C'est une très mauvaise suggestion. Voir le commentaire de @ user456814
Sos