W ~/.ssh/config, add:

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

If the config file is new, don’t forget to do chmod 600 ~/.ssh/config

Now you can do git clone git@github.com:{ORG_NAME}/{REPO_NAME}.git

• Where {ORG_NAME} is your GitHub user account (or organization account)‘s GitHub URI name.
• Zauważ, że po : jest dwukropek github.com zamiast ukośnika / - ponieważ nie jest to URI.
• I {REPO_NAME} jest nazwą URI twojego GitHub repo
• Na przykład dla jądra Linuksa byłoby to git clone git@github.com:torvalds/linux.git).

UWAGA: Na Linuksie i MacOSie sprawdź, czy uprawnienia na twoim IdentityFile wynoszą 400. SSH będzie odrzucać, w sposób niezrozumiały, klucze SSH, które są zbyt czytelne. Będzie to po prostu wyglądało na wiarygodne odrzucenie. Rozwiązanie, w tym przypadku, to:

chmod 400 ~/.ssh/id_rsa_github

Zmienna środowiskowa GIT_SSH_COMMAND:

Od Git w wersji 2.3.0, możesz użyć zmiennej środowiskowej GIT_SSH_COMMAND jak poniżej:

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

Zauważ, że -i może być czasem nadpisane przez plik konfiguracyjny, w tym przypadku powinieneś dać SSH pusty plik konfiguracyjny, jak poniżej:

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

Configuration core.sshCommand:

Od Git w wersji 2. 10.0, możesz skonfigurować to per repo lub globalnie, więc nie musisz już ustawiać zmiennej środowiskowej!

git config core.sshCommand "ssh -i ~/.ssh/id_rsa_example -F /dev/null"
git pull
git push

Nie ma nie ma direct sposobu, aby powiedzieć git, którego klucza prywatnego użyć, ponieważ opiera się na ssh do uwierzytelniania repozytorium. Istnieje jednak kilka sposobów na osiągnięcie celu:

Opcja 1: ssh-agent

Możesz użyć ssh-agent do tymczasowej autoryzacji klucza prywatnego.

Na przykład:

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

Opcja 2: GIT_SSH_COMMAND

Przekaż argumenty ssh używając zmiennej środowiskowej GIT_SSH_COMMAND (Git 2.3.0+).

Na przykład:

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

Możesz wpisać to wszystko w jednej linii - zignoruj $ i pomiń Nie ma **nie ma _direct_ sposobu**, aby powiedziećgit, którego klucza prywatnego użyć, ponieważ opiera się nassh` do uwierzytelniania repozytorium. Istnieje jednak kilka sposobów na osiągnięcie celu:

Opcja 1: ssh-agent

Możesz użyć ssh-agent do tymczasowej autoryzacji klucza prywatnego.

Na przykład:

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

Opcja 2: GIT_SSH_COMMAND

Przekaż argumenty ssh używając zmiennej środowiskowej GIT_SSH_COMMAND (Git 2.3.0+).

Na przykład:

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

Możesz wpisać to wszystko w jednej linii - zignoruj $ i pomiń .

Opcja 3: GIT_SSH

Podaj argumenty ssh używając zmiennej środowiskowej GIT_SSH do określenia alternatywy binarnej ssh.

Na przykład:

$ 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

Uwaga: Powyższe linie to linie poleceń powłoki (terminalu), które należy wkleić do terminala. Stworzą one plik o nazwie ssh, uczynią go wykonywalnym i (pośrednio) wykonają go.

Uwaga: GIT_SSH jest dostępne od v0.99.4 (2005).

Opcja 4: ~/.ssh/config

Użyj pliku ~/.ssh/config, jak sugerowano w innych odpowiedziach, aby określić lokalizację Twojego klucza prywatnego, np.

Napisz skrypt wywołujący ssh z żądanymi przez Ciebie argumentami i umieść nazwę pliku w $GIT_SSH. Albo po prostu umieść swoją konfigurację w ~/.ssh/config.

Użyj własnej konfiguracji hosta w ~/.ssh/config, jak to:

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

następnie użyj własnej nazwy hosta, jak to:

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

Jeśli nie chcesz określać zmiennych środowiskowych za każdym razem, gdy uruchamiasz git, nie chcesz kolejnego skryptu wrapper, nie/nie możesz uruchomić ssh-agent(1), ani nie chcesz pobierać innego pakietu tylko w tym celu, użyj zewnętrznego transportu 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)

Uważam to rozwiązanie za lepsze, ponieważ:

• To jest repozytorium/odległy specyficzny
• Unikaj skryptu wrapper bloat
• Nie potrzebujesz agenta SSH - przydatny jeśli chcesz nienadzorowanych klonów/push/pulls (e. g. in cron)
• Zdecydowanie nie jest potrzebne żadne zewnętrzne narzędzie.

Po zmaganiach z $GIT_SSH chciałbym podzielić się tym, co dla mnie zadziałało.

Na moich przykładach założę, że twój klucz prywatny znajduje się w /home/user/.ssh/jenkins

Błąd do uniknięcia: GIT__SSH wartość zawiera opcje

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

lub cokolwiek podobnego nie powiedzie się, ponieważ git spróbuje wykonać wartość jako plik. Z tego powodu należy utworzyć skrypt.

Przykład działania skryptu $GIT\_SSH /home/user/gssh.sh

Skrypt zostanie wywołany w następujący sposób:

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

Przykładowy skrypt pracujący może wyglądać jak:

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

Zauważ, że na końcu jest to ważna część $*.

Jeszcze bezpieczniejszą alternatywą, która zapobiegnie ewentualnym konfliktom z domyślnym plikiem konfiguracyjnym (oraz wyraźnie wskaże port, którego należy użyć) będzie:

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

Zakładając, że skrypt znajduje się w /home/user/gssh.sh, wówczas:

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

i wszystko będzie działać.

Możesz po prostu użyć ssh-ident zamiast tworzyć własne opakowanie.

Możesz przeczytać więcej na stronie: https://github.com/ccontavalli/ssh-ident

Ładuje klucze ssh na żądanie przy pierwszej potrzebie, raz, nawet przy wielu sesjach logowania, xtermach lub współdzielonych domach NFS.

Z malutkim plikiem konfiguracyjnym, może automatycznie ładować różne klucze i trzymać je oddzielnie w różnych agentach (do przekierowania agenta) w zależności od tego, co musisz zrobić.

Miałem klienta, który potrzebował osobnego konta githuba. Musiałem więc użyć osobnego klucza tylko do tego jednego projektu.

Moje rozwiązanie polegało na dodaniu tego do mojej .zshrc / .bashrc:

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

Kiedykolwiek chcę użyć gita do tego projektu, zastępuję “infogit” gitem:

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

Dla mnie jest to łatwiejsze do zapamiętania.

Więc ustawiłem zmienną env GIT_SSH na $HOME/bin/git-ssh.

Aby wesprzeć moją konfigurację repo dyktować, która tożsamość ssh ma być używana, mój plik ~/bin/git-ssh jest następujący:

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

Następnie mam globalne ustawienie konfiguracji gita:

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

A w każdym repozytorium gita mogę po prostu ustawić lokalną wartość gita ssh.identity:

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

Voila!

Jeśli możesz mieć inny adres e-mail dla każdej tożsamości, staje się to jeszcze prostsze, ponieważ możesz po prostu nazwać swoje klucze po swoich adresach e-mail, a następnie mieć git config’s user.email drive wybór klucza w ~/bin/git-ssh w następujący sposób:

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

Buduję na @shellholic i ten wątek SO z kilkoma teakami. Używam GitHuba jako przykładu i zakładam, że masz klucz prywatny w ~/.ssh/github (inaczej patrz ten wątek SO ) i że dodałeś klucz publiczny do swojego profilu GitHuba (inaczej patrz pomoc GitHuba ).

Jeśli to konieczne, utwórz nowy plik konfiguracyjny SSH w ~/.ssh/config i zmień uprawnienia na 400

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

Dodaj to do pliku ~/.ssh/config:

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

Jeśli masz już skonfigurowany zdalnie, możesz chcieć go usunąć, w przeciwnym razie nadal możesz zostać poproszony o podanie nazwy użytkownika i hasła:

git remote rm origin

Następnie dodaj pilota do repozytorium git i zwróć uwagę na dwukropek przed nazwą użytkownika:

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

A potem polecenia git działają normalnie, np. g.:

git push origin master
git pull origin

@HeyWatchThis on this SO thread suggested adding IdentitiesOnly yes to prevent the SSH default behaviour of sending the identity file matching the default filename for each protocol. Zobacz ten wątek, aby uzyskać więcej informacji i odnośników.

Moje rozwiązanie było następujące:

stwórz skrypt:

#!/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

a następnie, gdy będziesz musiał zmienić działanie var:

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

Nie zapomnij o dodatkowej kropce! To sprawia, że skrypt ustawia vars środowiskowy! -key i –port są opcjonalne.

Generalnie, chcesz użyć do tego ~/.ssh/config. Wystarczy sparować adresy serwerów z kluczami, których chcesz dla nich używać w następujący sposób:

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

Host * oznacza dowolny serwer, więc używam go do ustawienia ~/.ssh/id_rsa jako domyślnego klucza do użycia.

Wystarczy użyć komend ssh-agent i 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>

Po wykonaniu powyższych komend, możesz użyć obu klawiszy jednocześnie. Po prostu wpisz

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

aby sklonować repozytorium.

Musisz wykonać powyższą komendę po restarcie maszyny.

# 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

Mimo, że pytanie nie prosi o to, załączam tę odpowiedź dla każdego, kto chce rozwiązać ten sam problem tylko specjalnie dla gitlab .

The gitlab solution

Próbowałem użyć podejścia environment-variables , ale nawet the git documentation zaleca użycie ~/.ssh/config dla czegoś więcej niż tylko prostego przypadku. W moim przypadku pcham do serwera gitlab - i chciałem to zrobić jako konkretny użytkownik - co oczywiście jest zdefiniowane przez prywatny klucz podczas uwierzytelniania , a nie przez nazwę użytkownika git. Raz zaimplementowany wykonuję po prostu:

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

Konfiguracja

Przypomnij lokalizację swojego private-key /myfolder/.ssh/my_gitlab_id_rsa w moim przypadku.

Add an entry in ~/.ssh/config:

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

Add the 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"

As a bonus, I perform my commits on this same host as a specific user with this git-alias :

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

Objaśnienie

Wszystkie powyższe założenia zakładają, że odpowiednim pilotem jest origin i odpowiedni oddział jest aktualnie sprawdzony. Dla przypomnienia natknąłem się na kilka punktów które wymagały zaadresowania:

• Rozwiązanie wymaga stworzenia nowego pilota gitlab_as_me, a ja nie lubiłem widzieć dodatkowego pilota wiszącego w moim drzewie więc usuwam go po zakończeniu
• W celu stworzenia pilota, istnieje potrzeba wygenerowania adresu url pilota w locie - w przypadku gitlab'a zostało to osiągnięte za pomocą prostego bash'a wycięcie
• Podczas wykonywania pchnięcia do gitlab_as_me musisz być konkretny co do gałęzi, którą pchasz
• Po wykonaniu pchnięcia Twój lokalny wskaźnik origin musi być “zaktualizowany”, aby dopasować go do gitlab_as_me (git pull origin $branch robi to)

When you have multiple git account and you want different ssh key

You have to follow the same step for generating the ssh key, but be sure you

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

Enter the path you want to save(Ex: my-pc/Desktop/. ssh/ed25519)

Dodaj klucz publiczny do gitlab Jak dodać klucz ssh do gitlab )

Musisz stworzyć nową tożsamość ssh używając poniższej komendy

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

Używam gita w wersji 2.16 i nie potrzebuję ani jednego skryptu, ani nawet konfiguracji, ani zmodyfikowanych poleceń.

• Po prostu skopiowałem mój klucz prywatny do .ssh/id_rsa
• ustaw uprawnienia na 600

i git czyta na klucz automatycznie. Ja o nic nie pytam, a on nie rzuca błędem. Po prostu działa dobrze.

Jeśli musisz połączyć się z tym samym hostem za pomocą różnych kluczy, możesz to osiągnąć przez:

1. Skonfiguruj ~/.ssh/config z różnymi hostami, ale z tymi samymi nazwami hostów.
2. Sklonuj repo używając odpowiedniego hosta.

Przykład:

~/.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

Następnie nie klonuj swoje repo jak:

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

musisz zrobić

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