sshhat die -iOption anzugeben, welche private Schlüsseldatei für die 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. Der Standard ist ~/.ssh/identityfür Protokollversion 1 und ~/.ssh/id_rsaund ~/.ssh/id_dsafür Protokollversion 2. Identität Dateien auch auf einer Pro-Host - Basis in der Konfigurationsdatei angegeben werden. Es ist möglich, mehrere -iOptionen (und mehrere in den Konfigurationsdateien angegebene Identitäten) festzulegen.

Gibt es eine ähnliche Möglichkeit, festzustellen, gitwelche private Schlüsseldatei auf einem System mit mehreren privaten Schlüsseln im ~/.sshVerzeichnis verwendet werden soll?

In ~/.ssh/confighinzufügen:

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

Jetzt kannst du tun git clone git@github.com:username/repo.git.

ANMERKUNG: Stellen Sie sicher, dass die Berechtigungen für IdentityFile 400 sind. SSH lehnt zu lesende SSH-Schlüssel in nicht eindeutiger Weise ab. Es sieht aus wie eine Ablehnung des Berechtigungsnachweises. In diesem Fall lautet die Lösung:

chmod 400 ~/.ssh/id_rsa_github

Umgebungsvariable GIT_SSH_COMMAND:

Ab Git Version 2.3.0 können Sie die Umgebungsvariable folgendermaßen verwenden GIT_SSH_COMMAND:

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

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

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, sodass 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

Es gibt keine direkte Möglichkeit , gitden zu verwendenden privaten Schlüssel zu bestimmen, da er sshfür die Repository-Authentifizierung erforderlich ist. Es gibt jedoch noch einige Möglichkeiten, um Ihr Ziel zu erreichen:

Option 1: ssh-agent

Mit können Sie ssh-agentIhren privaten Schlüssel vorübergehend autorisieren.

Zum Beispiel:

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

Option 2: GIT_SSH_COMMAND

GIT_SSH_COMMANDÜbergeben Sie die ssh-Argumente mithilfe der Umgebungsvariablen (Git 2.3.0+).

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 einer Zeile eingeben - ignorieren Sie $und lassen Sie das \.}

Option 3: GIT_SSH

Übergeben Sie die ssh-Argumente mithilfe der GIT_SSHUmgebungsvariablen, um eine alternative sshBinärdatei 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 erstellen eine Datei mit dem Namen ssh, machen sie ausführbar und führen sie (indirekt) aus.}

^{Hinweis: GIT_SSHist verfügbar seit v0.99.4 (2005).}

Option 4: ~/.ssh/config

Verwenden Sie die ~/.ssh/configDatei wie in anderen Antworten vorgeschlagen, um den Speicherort Ihres privaten Schlüssels anzugeben, z

Host github.com
  User git
  Hostname github.com
  IdentityFile ~/.ssh/id_rsa

Schreiben Sie ein Skript, das sshmit den gewünschten Argumenten aufgerufen wird, und geben Sie den Dateinamen des Skripts ein $GIT_SSH. Oder geben Sie einfach Ihre Konfiguration ein ~/.ssh/config.

Wenn Sie nicht jedes Mal Umgebungsvariablen angeben müssen, wenn Sie git ausführen, kein weiteres Wrapper-Skript möchten, ssh-agent (1) nicht ausführen können oder ein anderes Paket nur für diesen Zweck herunterladen möchten, verwenden Sie das git -remote-ext (1) externer Transport:

$ 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 überlegen, weil:

• Es ist repository- / remote-spezifisch
• Vermeiden Sie das Aufblähen von Wrapper-Skripten
• Benötigen Sie nicht den SSH-Agenten - nützlich, wenn Sie unbeaufsichtigte Klone / Push / Pulls (z. B. in Cron) möchten
• Auf jeden Fall wird kein externes Tool benötigt

Verwenden Sie die benutzerdefinierte Hostkonfiguration ~/.ssh/configwie folgt :

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

Verwenden Sie dann Ihren benutzerdefinierten Hostnamen wie folgt:

git remote add thuc git@gitlab-as-thuc:your-repo.git  

Nach meinem Kampf mit $GIT_SSHmöchte ich mitteilen, was für mich funktioniert hat.

Anhand meiner Beispiele gehe ich davon aus, dass sich Ihr privater Schlüssel unter befindet/home/user/.ssh/jenkins

Zu vermeidender Fehler: GIT_SSH-Wert enthält Optionen

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

oder was auch immer ähnliches wird fehlschlagen, da git versuchen wird, den Wert als Datei auszuführen . Aus diesem Grund müssen Sie ein Skript erstellen.

Funktionsbeispiel für das Skript $ GIT_SSH /home/user/gssh.sh

Das Skript wird wie folgt aufgerufen:

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

Das Beispielskript könnte folgendermaßen 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 Standardkonfigurationsdatei verhindert (und den zu verwendenden Port explizit erwähnt), 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 müssen Sie:

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

und alles soll funktionieren.

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

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

Bei Bedarf werden SSH-Schlüssel geladen, auch bei mehreren Anmeldesitzungen, xterms oder NFS-Shared Homes.

Mit einer winzigen Konfigurationsdatei können automatisch verschiedene Schlüssel geladen und in verschiedenen Agenten (für die Agentenweiterleitung) getrennt werden, je nachdem, was Sie tun müssen.

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

Meine Lösung war, dies zu meinem .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 einfacher, sich zu erinnern.

Also habe ich die Variable GIT_SSH env auf gesetzt $HOME/bin/git-ssh.

Um zu unterstützen, dass meine Repo-Konfiguration festlegt, welche SSH-Identität verwendet werden soll, ist meine ~/bin/git-sshDatei 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 in jedem Git-Repository kann ich einfach einen lokalen ssh.identityGit-Konfigurationswert festlegen :

$ 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 dies noch einfacher, da Sie Ihre Schlüssel einfach nach Ihren E-Mail-Adressen benennen und die user.email der git config die Schlüsselauswahl folgendermaßen steuern ~/bin/git-sshlassen können:

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

Meine Lösung war:

erstelle ein Skript:

#!/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 Extrapunkt !! das Skript setzt die Umgebungen unterschiedlich !! --key und --port sind optional.

Im Allgemeinen möchten Sie ~/.ssh/configdies verwenden. Koppeln Sie einfach die Serveradressen wie folgt mit den Schlüsseln, die Sie für sie verwenden möchten:

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 ~/.ssh/id_rsaals zu verwendenden Standardschlüssel.

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 haben ~/.ssh/github(siehe sonst diesen SO-Thread ) und dass Sie den öffentlichen Schlüssel zu Ihrem GitHub-Profil hinzugefügt haben (siehe sonst die Hilfe von GitHub ).

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

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

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

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

Wenn Sie bereits eine Remote-Einrichtung haben, möchten Sie diese möglicherweise löschen. Andernfalls werden Sie möglicherweise weiterhin zur Eingabe von Benutzername und Kennwort aufgefordert:

git remote rm origin

Fügen Sie dann dem Git-Repository ein Remote 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, zB:

git push origin master
git pull origin 

@HeyWatchThis in diesem SO-Thread schlug das Hinzufügen vor IdentitiesOnly yes, um das SSH-Standardverhalten beim Senden der Identitätsdatei zu verhindern, die dem Standarddateinamen für jedes Protokoll entspricht. In diesem Thread finden Sie weitere Informationen und Verweise.

Verwenden Sie einfach ssh-agentund ssh-addBefehle.

# 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. Tipp einfach

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

um dein Repository zu klonen.

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

Ich benutze Git Version 2.16 und ich brauche kein einziges Skript, nicht einmal eine Konfiguration oder modifizierte Befehle.

• Habe gerade meinen privaten Schlüssel nach .ssh / id_rsa kopiert
• Setzen Sie die Berechtigungen auf 600

Und Git liest zu Schlüssel automatisch. Ich frage nichts und es wird kein Fehler ausgegeben. Funktioniert einfach gut.

Während die Frage nicht danach fragt, schließe ich diese Antwort für alle anderen ein, die das gleiche Problem speziell für gitlab lösen möchten .

Die Gitlab-Lösung

Ich habe versucht, den Umgebungsvariablen- Ansatz zu verwenden, aber selbst in der Git-Dokumentation wird die Verwendung ~/.ssh/configfür mehr als den einfachen Fall empfohlen . In meinem Fall drücke ich auf einen Gitlab- Server - und ich wollte es als bestimmter Benutzer -, der natürlich durch den privaten Schlüssel während der Authentifizierung und nicht durch den Benutzernamen definiert wird git. 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...]

Konfiguration

Erinnern Sie sich an den Speicherort Ihres privaten Schlüssels /myfolder/.ssh/my_gitlab_id_rsa in meinem Fall.

Eintrag hinzufügen in ~/.ssh/config:

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

Fügen Sie den Git-Alias ​​hinzu 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 demselben Host wie ein bestimmter Benutzer mit diesem git-Alias ​​aus :

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

Erläuterung

In allen oben genannten Fällen wird davon originausgegangen, dass sich die betreffende Fernbedienung in befindet und der betreffende Zweig derzeit ausgecheckt ist. Als Referenz stieß ich auf einige Punkte, die angesprochen werden mussten:

• Für die Lösung muss eine neue Fernbedienung erstellt werden gitlab_as_me, und es hat mir nicht gefallen, dass die zusätzliche Fernbedienung in meinem Protokollbaum herumhängt, sodass ich sie nach Abschluss entferne
• Um die Fernbedienung zu erstellen, muss die URL der Fernbedienung im laufenden Betrieb generiert werden - im Fall von gitlab wurde dies mit einem einfachen Bash- Cut erreicht
• Wenn Sie einen Push-to- gitlab_as_meVorgang ausführen, müssen Sie genau angeben, welchen Zweig Sie pushen
• Nach der Durchführung des Drucks Ihrer lokale originBedürfnisse Zeiger „aktualisiert“ anzupassen , um zu gitlab_as_me(das git pull origin $branchtut dies)

Wenn Sie mehrere Git-Konto haben und unterschiedliche SSH-Schlüssel möchten

Sie müssen den gleichen Schritt ausführen, um den SSH-Schlüssel zu generieren

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

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

Fügen Sie den öffentlichen Schlüssel zu Ihrem Gitlab hinzu ( So fügen Sie den SSH- Schlüssel zu Gitlab hinzu )

Sie müssen die SSH-Identität mit dem folgenden Befehl neu definieren

ssh-add ~/my-pc/Desktop/.ssh/ed25519

    # 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