2011-01-12 18:20:31 +0000 2011-01-12 18:20:31 +0000
702
702

Wie kann man git mitteilen, welcher private Schlüssel verwendet werden soll?

ssh hat die Option -i, um anzugeben, welche Datei mit dem privaten Schlüssel bei der Authentifizierung verwendet werden soll:

-i identity_file

Wählt eine Datei aus, aus der die Identität (privater Schlüssel) für die RSA- oder DSA-Authentifizierung gelesen wird.  Die Voreinstellung ist ~/.ssh/identity für Protokollversion 1, und ~/.ssh/id_rsa und ~/.ssh/id_dsa für Protokollversion 2 Identitätsdateien können auch auf einer Pro-Host-Basis in der Konfigurationsdatei.&nbsp angegeben werden. Es ist möglich, mehrere -i-Optionen (und mehrere Identitäten, die in Konfigurationsdateien angegeben sind) zu haben.

Gibt es eine ähnliche Möglichkeit, git mitzuteilen, welche private Schlüsseldatei auf einem System mit mehreren privaten Schlüsseln im Verzeichnis ~/.ssh zu verwenden ist?

Antworten (19)

720
720
720
2011-01-12 19:36:21 +0000

Fügen Sie in ~/.ssh/config hinzu:

host github.com
 HostName github.com
 IdentityFile ~/.ssh/id_rsa_github
 User git

Wenn die Konfigurationsdatei neu ist, vergessen Sie nicht, chmod 600 ~/.ssh/config

zu tun. Jetzt können Sie git clone git@github.com:{ORG_NAME}/{REPO_NAME}.git

tun - wobei {ORG_NAME} der GitHub-URI-Name Ihres GitHub-Benutzerkontos (oder Organisationskontos) ist. - Beachten Sie, dass nach : anstelle des Schrägstrichs github.com ein Doppelpunkt / steht - da dies kein URI ist. - Und {REPO_NAME} ist der URI-Name Ihres GitHub-Repos - Zum Beispiel für den Linux-Kernel wäre dies git clone git@github.com:torvalds/linux.git).

HINWEIS: Überprüfen Sie unter Linux und MacOS, dass die Berechtigungen auf Ihrer IdentityFile 400 sind. SSH lehnt auf nicht eindeutig explizite Weise SSH-Schlüssel ab, die zu lesbar sind. Es wird nur wie eine Zurückweisung von Berechtigungsnachweisen aussehen. Die Lösung ist in diesem Fall:

chmod 400 ~/.ssh/id_rsa_github
387
387
387
2015-05-08 09:43:07 +0000

Umgebungsvariable GIT_SSH_COMMAND:

Ab Git Version 2.3.0 können Sie die Umgebungsvariable GIT_SSH_COMMAND wie folgt verwenden:

GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_example" git clone example

Beachten Sie, dass -i manchmal von Ihrer Konfigurationsdatei überschrieben werden kann. In diesem Fall sollten Sie SSH eine leere Konfigurationsdatei geben, wie diese:

GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_example -F /dev/null" git clone example

Konfiguration core.sshCommand:

Ab Git Version 2. 10.0 können Sie dies per Repo oder global konfigurieren, so dass Sie die Umgebungsvariable nicht mehr setzen müssen!

git config core.sshCommand "ssh -i ~/.ssh/id_rsa_example -F /dev/null"
git pull
git push
122
122
122
2015-01-23 22:08:00 +0000

Es gibt keine direkte Möglichkeit, git mitzuteilen, welcher private Schlüssel verwendet werden soll, weil er sich bei der Authentifizierung des Repositorys auf ssh verlässt. Es gibt jedoch noch einige Möglichkeiten, Ihr Ziel zu erreichen:

Option 1: ssh-agent

Sie können ssh-agent verwenden, um Ihren privaten Schlüssel vorübergehend zu autorisieren.

Zum Beispiel:

$ ssh-agent sh -c 'ssh-add ~/.ssh/id_rsa; git fetch user@host'

Option 2: GIT_SSH_COMMAND

Übergeben Sie die ssh-Argumente, indem Sie die Umgebungsvariable GIT_SSH_COMMAND (Git 2.3.0+) verwenden.

Zum Beispiel:

$ GIT_SSH_COMMAND='ssh -i ~/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' \
  git clone user@host

Sie können dies alles in eine Zeile eingeben - ignorieren Sie $ und lassen Sie die Es gibt **keine _direkte_ Möglichkeit**,gitmitzuteilen, welcher private Schlüssel verwendet werden soll, weil er sich bei der Authentifizierung des Repositorys aufssh` verlässt. Es gibt jedoch noch einige Möglichkeiten, Ihr Ziel zu erreichen:

Option 1: ssh-agent

Sie können ssh-agent verwenden, um Ihren privaten Schlüssel vorübergehend zu autorisieren.

Zum Beispiel:

$ ssh-agent sh -c 'ssh-add ~/.ssh/id_rsa; git fetch user@host'

Option 2: GIT_SSH_COMMAND

Übergeben Sie die ssh-Argumente, indem Sie die Umgebungsvariable GIT_SSH_COMMAND (Git 2.3.0+) verwenden.

Zum Beispiel:

$ GIT_SSH_COMMAND='ssh -i ~/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' \
  git clone user@host

Sie können dies alles in eine Zeile eingeben - ignorieren Sie $ und lassen Sie die weg.

Option 3: GIT_SSH

Übergeben Sie die ssh-Argumente, indem Sie die Umgebungsvariable GIT_SSH verwenden, um alternative ssh binär anzugeben.

Zum Beispiel:

$ echo 'ssh -i ~/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH='./ssh' git clone user@host

Hinweis: Die obigen Zeilen sind Shell-(Terminal-)Befehlszeilen, die Sie in Ihr Terminal einfügen sollten. Sie werden eine Datei mit dem Namen ssh erzeugen, sie ausführbar machen und (indirekt) ausführen.

Hinweis: GIT_SSH ist verfügbar seit v0.99.4 (2005).

Option 4: ~/.ssh/config

Verwenden Sie die Datei ~/.ssh/config wie in anderen Antworten vorgeschlagen, um den Ort Ihres privaten Schlüssels anzugeben, z.B.

Host github.com
  User git
  Hostname github.com
  IdentityFile ~/.ssh/id_rsa
33
33
33
2011-01-12 18:25:51 +0000

Schreiben Sie ein Skript, das ssh mit den gewünschten Argumenten aufruft, und setzen Sie den Dateinamen des Skripts in $GIT_SSH. Oder geben Sie einfach Ihre Konfiguration in ~/.ssh/config ein.

22
22
22
2016-05-17 15:03:09 +0000

Verwenden Sie die benutzerdefinierte Hostkonfiguration in ~/.ssh/config, etwa so:

Host gitlab-as-thuc  
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa.thuc
    IdentitiesOnly yes

dann verwenden Sie Ihren benutzerdefinierten Hostnamen wie folgt:

git remote add thuc git@gitlab-as-thuc:your-repo.git
22
22
22
2015-07-21 19:44:50 +0000

Wenn Sie nicht jedes Mal, wenn Sie git ausführen, Umgebungsvariablen angeben müssen, kein weiteres Wrapper-Skript wünschen, ssh-agent(1) nicht ausführen wollen/können und auch kein weiteres Paket nur dafür herunterladen wollen, verwenden Sie den externen Transport git-remote-ext(1):

$ git clone 'ext::ssh -i $HOME/.ssh/alternate_id git.example.com %S /path/to/repository.git'
Cloning into 'repository'
(...)
$ cd repository
$ git remote -v
origin ext::ssh -i $HOME/.ssh/alternate_id git.example.com %S /path/to/repository.git (fetch)
origin ext::ssh -i $HOME/.ssh/alternate_id git.example.com %S /path/to/repository.git (push)

Ich halte diese Lösung für besser, weil:

  • Sie ist repository-/remote-spezifisch
  • Vermeiden Sie eine Aufblähung des Wrapper-Skripts
  • Benötigen den SSH-Agenten nicht – nützlich, wenn Sie unbeaufsichtigte Klons/Push/Pulls wollen (e. g. in cron)
  • Definitiv, kein externes Werkzeug erforderlich
17
17
17
2015-05-28 17:09:40 +0000

Nach meinem Kampf mit $GIT_SSH möchte ich Ihnen mitteilen, was bei mir funktioniert hat.

Anhand meiner Beispiele gehe ich davon aus, dass Sie Ihren privaten Schlüssel unter /home/user/.ssh/jenkins

zu vermeidender Fehler haben: Der GIT_SSH-Wert enthält die Optionen

$ export GIT_SSH="ssh -i /home/user/.ssh/jenkins"

oder was auch immer ähnlich funktioniert, schlägt fehl, da git versuchen wird, den Wert als Datei auszuführen. Aus diesem Grund müssen Sie ein Skript erstellen.

Arbeitsbeispiel eines $GIT_SSH-Skripts /home/user/gssh.sh

Das Skript wird wie folgt aufgerufen:

$ $GIT_SSH [username@]host [-p <port>] <command>

Das funktionierende Beispiel-Skript könnte so aussehen:

#!/bin/sh
ssh -i /home/user/.ssh/jenkins $*

Beachten Sie das $* am Ende, es ist ein wichtiger Teil davon.

Eine noch sicherere Alternative, die jeden möglichen Konflikt mit irgendetwas in Ihrer Standard-Konfigurationsdatei (plus expliziter Angabe des zu verwendenden Ports) verhindern würde, wäre:

#!/bin/sh
ssh -i /home/user/.ssh/jenkins -F /dev/null -p 22 $*

Angenommen, das Skript ist in /home/user/gssh.sh, dann sollten Sie:

$ export GIT_SSH=/home/user/gssh.sh

und alles sollte funktionieren.

7
7
7
2013-03-23 01:35:15 +0000

Sie können einfach ssh-ident verwenden, anstatt einen eigenen Wrapper zu erstellen.

Weitere Informationen finden Sie unter https://github.com/ccontavalli/ssh-ident

Es lädt ssh-Schlüssel auf Anforderung, wenn es zum ersten Mal benötigt wird, einmal, sogar bei mehreren Login-Sitzungen, xterms oder NFS Shared Homes.

Mit einer winzigen Konfigurationsdatei kann es automatisch verschiedene Schlüssel laden und sie in verschiedenen Agenten (zur Agentenweiterleitung) getrennt halten, je nachdem, was Sie tun müssen.

6
6
6
2018-03-26 19:26:38 +0000

Ich hatte einen Kunden, der ein separates Github-Konto benötigte. Also musste ich einen separaten Schlüssel nur für dieses eine Projekt verwenden.

Meine Lösung bestand darin, diesen zu meiner .zshrc / .bashrc hinzuzufügen:

alias infogit="GIT_SSH_COMMAND=\"ssh -i ~/.ssh/id_specialkey\" git $@"

Wann immer ich git für dieses Projekt verwenden möchte, ersetze ich “infogit” durch git:

infogit commit -am "Some message" && infogit push

Für mich ist es leichter zu merken.

5
5
5
2018-12-04 22:21:13 +0000

Also setze ich die GIT_SSH env-Variable auf $HOME/bin/git-ssh

Um zu unterstützen, dass meine Repo-Konfiguration vorschreibt, welche ssh-Identität verwendet werden soll, lautet meine ~/bin/git-ssh-Datei wie folgt:

#!/bin/sh
ssh -i $(git config --get ssh.identity) -F /dev/null -p 22 $*

Dann habe ich eine globale Git-Konfigurationseinstellung:

$ git config --global ssh.identity ~/.ssh/default_id_rsa

Und innerhalb jedes Git-Repositorys kann ich einfach einen lokalen ssh.identity-Git-Konfigurationswert setzen:

$ git config --local ssh.identity ~/.ssh/any_other_id_rsa

Voila!

Wenn Sie für jede Identität eine andere E-Mail-Adresse haben können, wird es sogar noch einfacher, denn Sie können einfach Ihre Schlüssel nach Ihren E-Mail-Adressen benennen und dann die git-Konfiguration user.email die Schlüsselauswahl in einer ~/bin/git-ssh wie folgt steuern lassen:

#!/bin/sh
ssh -i $HOME/.ssh/$(git config --get user.email) -F /dev/null -p 22 $*
3
3
3
2018-05-03 10:17:14 +0000

Ich baue auf @shellholic und diesem SO-Thread mit ein paar Teaks auf. Ich verwende GitHub als Beispiel und gehe davon aus, dass Sie einen privaten Schlüssel in ~/.ssh/github haben (ansonsten siehe dieser SO-Thread ) und dass Sie den öffentlichen Schlüssel zu Ihrem GitHub-Profil hinzugefügt haben (ansonsten siehe GitHub’s Hilfe ).

Erstellen Sie bei Bedarf eine neue SSH-Konfigurationsdatei unter ~/.ssh/config und ändern Sie die Berechtigungen in 400

touch ~/.ssh/config
chmod 600 ~/.ssh/config

Fügen Sie dies zur Datei ~/.ssh/config hinzu:

Host github.com
    IdentityFile ~/.ssh/github
    IdentitiesOnly yes

Wenn Sie bereits ein Remote-Setup haben, möchten Sie es vielleicht löschen, andernfalls werden Sie möglicherweise immer noch nach Benutzername und Passwort gefragt:

git remote rm origin

Fügen Sie dann ein Remote zum git-Repository hinzu und beachten Sie den Doppelpunkt vor dem Benutzernamen:

git remote add origin git@github.com:user_name/repo_name.git

Und dann funktionieren git-Befehle normal, e. g.:

git push origin master
git pull origin

@HeyWatchThis on this SO thread schlug vor, IdentitiesOnly yes hinzuzufügen, um das SSH-Standardverhalten zu verhindern, die Identitätsdatei zu senden, die dem Standard-Dateinamen für jedes Protokoll entspricht. Weitere Informationen und Referenzen finden Sie in diesem Thread.

3
3
3
2015-12-05 12:22:32 +0000

Meine Lösung war folgende:

ein Skript erstellen:

#!/bin/bash
KEY=dafault_key_to_be_used
PORT=10022 #default port...
for i in $@;do
   case $i in
    --port=*)
        PORT="${i:7}";;
    --key=*)KEY="${i:6}";;
   esac
done
export GIT_SSH_COMMAND="ssh -i $HOME/.ssh/${KEY} -p ${PORT}"
echo Command: $GIT_SSH_COMMAND

dann, wenn Sie den var-Lauf ändern müssen:

. ./thescript.sh [--port=] [--key=]

Vergessen Sie nicht den zusätzlichen Punkt!! dies macht das Skript die Umgebungen vars! –key und –port sind optional.

3
3
3
2016-02-11 22:44:57 +0000

Im Allgemeinen möchten Sie dafür ~/.ssh/config verwenden. Paaren Sie einfach Serveradressen mit den Schlüsseln, die Sie dafür verwenden wollen, wie folgt:

Host github.com
  IdentityFile ~/.ssh/id_rsa.github
Host heroku.com
  IdentityFile ~/.ssh/id_rsa.heroku
Host *
  IdentityFile ~/.ssh/id_rsa

Host * bezeichnet einen beliebigen Server, daher verwende ich ihn, um ~/.ssh/id_rsa als den standardmäßig zu verwendenden Schlüssel festzulegen.

2
2
2
2018-07-05 09:53:09 +0000

Verwenden Sie einfach die Befehle ssh-agent und ssh-add.

# create an agent
ssh-agent

# add your default key
ssh-add ~/.ssh/id_rsa

# add your second key
ssh-add ~/.ssh/<your key name>

Nachdem Sie die obigen Befehle ausgeführt haben, können Sie beide Tasten gleichzeitig verwenden. Geben Sie einfach

git clone git@github.com:<yourname>/<your-repo>.git

ein, um Ihr Repository zu klonen.

Sie müssen den obigen Befehl ausführen, nachdem Sie Ihren Rechner neu gestartet haben.

1
1
1
2019-08-31 05:43:47 +0000
# start :: how-to use different ssh identity files

    # create the company identity file
    ssh-keygen -t rsa -b 4096 -C "first.last@corp.com"
    # save private key to ~/.ssh/id_rsa.corp, 
    cat ~/.ssh/id_rsa.corp.pub # copy paste this string into your corp web ui security ssh keys

    # create your private identify file
    ssh-keygen -t rsa -b 4096 -C "me@gmail.com"
    # save private key to ~/.ssh/id_rsa.me, note the public key ~/.ssh/id_rsa.me.pub
    cat ~/.ssh/id_rsa.me.pub # copy paste this one into your githubs, private keys

    # clone company internal repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone git@git.in.corp.com:corp/project.git

    export git_msg="my commit msg with my corporate identity, explicitly provide author"
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <first.last@corp.com>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push 
    # and verify 
    clear ; git log --pretty --format='%h %ae %<(15)%an ::: %s

    # clone public repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone git@github.com:acoolprojectowner/coolproject.git

    export git_msg="my commit msg with my personal identity, again author "
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <first.last@gmail.com>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.me -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push ; 
    # and verify 
    clear ; git log --pretty --format='%h %ae %<(15)%an ::: %s

    # stop :: how-to use different ssh identity files
1
1
1
2019-01-07 18:26:23 +0000

Während die Frage nicht danach verlangt, füge ich diese Antwort für alle anderen ein, die dasselbe Problem nur speziell für gitlab lösen wollen.

Die gitlab-Lösung

Ich habe versucht, den Umgebungsvariablen -Ansatz zu verwenden, aber selbst die git-Dokumentation empfiehlt die Verwendung von ~/.ssh/config für alles, was über den einfachen Fall hinausgeht. In meinem Fall dränge ich auf einen gitlab -Server - und das wollte ich als spezifischer Benutzer tun -, der natürlich durch die private key während authentication und nicht durch den Benutzernamen git definiert ist. Nach der Implementierung führe ich einfach Folgendes aus:

~/myrepo> git mycommit -m "Important Stuff"
~/myrepo> git mypush
[proceed to enter passphrase for private key...]

Setup

In meinem Fall erinnere ich mich an den Standort Ihres private-key /myfolder/.ssh/my_gitlab_id_rsa.

Hinzufügen eines Eintrags in ~/.ssh/config:

Host gitlab-delegate
    HostName gitlab.mydomain.com
    User git
    IdentityFile /myfolder/.ssh/my_gitlab_id_rsa
    IdentitiesOnly yes

Hinzufügen der git-alias in ~/.gitconfig:

mypush = "!f() { \
           path=$(git config --get remote.origin.url | cut -d':' -f2); \
           branch=$(git rev-parse --abbrev-ref HEAD); \
           git remote add gitlab_as_me git@gitlab-delegate:$path && \
           git push gitlab_as_me $branch && \
           git pull origin $branch; \
           git remote remove gitlab_as_me; \
         }; f"

Als Bonus führe ich meine Commits auf diesem selben Host als ein bestimmter Benutzer mit diesem git-alias durch:

mycommit = "!f() { \
             git -c "user.name=myname" -c "user.email=myname@mysite.com" commit \"$@\"; \
           }; f"

Erläuterung

Bei allen obigen Ausführungen wird davon ausgegangen, dass es sich bei dem betreffenden Remote-Rechner um origin handelt und die betreffende Zweigstelle derzeit ausgecheckt ist. Als Referenz habe ich einige Punkte aufgelistet, die angesprochen werden mussten:

  • Die Lösung erfordert die Erstellung einer neuen Fernbedienung gitlab_as_me, und mir gefiel es nicht, die zusätzliche Fernbedienung die in meinem Log-Baum herumhängt zu sehen, also entferne ich sie, wenn ich fertig bin
  • Um die Fernbedienung zu erstellen, Es besteht die Notwendigkeit, die Url der Gegenstelle im laufenden Betrieb zu generieren - im Fall von gitlab wurde dies mit einer einfachen Bash cut erreicht - Wenn Sie einen Push an gitlab_as_me durchführen, müssen Sie genau angeben, welchen Zweig Sie pushen - Nach der Durchführung des Push muss Ihr lokaler origin-Zeiger “aktualisiert” werden, damit er mit gitlab_as_me übereinstimmt (der git pull origin $branch tut dies)
1
1
1
2019-04-06 20:42:39 +0000

Wenn Sie mehrere git-Accounts haben und einen unterschiedlichen ssh-Schlüssel wünschen

Sie müssen den gleichen Schritt für die Generierung des ssh-Schlüssels befolgen, aber stellen Sie sicher, dass Sie

ssh-keygen -t ed25519 -C "your-email-id@gmail.com"

Geben Sie den Pfad ein, den Sie speichern möchten(Bsp.: my-pc/Desktop/. ssh/ed25519)

Fügen Sie den öffentlichen Schlüssel zu Ihrem gitlab hinzu Wie füge ich den ssh-Schlüssel zu gitlab hinzu )

Sie müssen eine neue ssh-Identität mit dem folgenden Befehl erstellen

ssh-add ~/my-pc/Desktop/.ssh/ed25519
0
0
0
2018-06-06 04:37:12 +0000

Ich benutze git Version 2.16 und ich brauche kein einziges Stück Skript, nicht einmal eine Konfiguration oder modifizierte Befehle.

  • Kopierte einfach meinen privaten Schlüssel nach .ssh/id_rsa
  • setzte die Berechtigungen auf 600

Und git liest den Schlüssel automatisch ein. Ich frage nichts und es wirft keinen Fehler. Es funktioniert einfach gut.

0
0
0
2020-01-24 00:58:26 +0000

Wenn Sie eine Verbindung zum gleichen Host mit unterschiedlichen Schlüsseln herstellen müssen, können Sie dies erreichen durch:

  1. Konfigurieren Sie die ~/.ssh/config mit verschiedenen Hosts, aber gleichen Hostnamen:
  2. Klonen Sie Ihr Repo unter Verwendung des entsprechenden Hosts.

Beispiel:

~/.ssh/config

Host work
 HostName bitbucket.org
 IdentityFile ~/.ssh/id_rsa_work
 User git

Host personal
 HostName bitbucket.org
 IdentityFile ~/.ssh/id_rsa_personal
 User git

Dann anstelle des Klonens Ihres Repos wie:

git clone git@bitbucket.org:username/my-work-project.git
git clone git@bitbucket.org:username/my-personal-project.git

müssen Sie

git clone git@work:username/my-work-project.git
git clone git@personal:username/my-personal-project.git