Jak powiedzieć git, którego klucza prywatnego użyć?


646

sshma -iopcję określenia, którego pliku klucza prywatnego użyć podczas uwierzytelniania:

-i identity_file

    Wybiera plik, z którego odczytywana jest tożsamość (klucz prywatny) dla uwierzytelnienia RSA lub DSA. Domyślną wartością jest ~/.ssh/identitydla protokołu w wersji 1, a ~/.ssh/id_rsai ~/.ssh/id_dsadla wersji protokołu 2. Pliki tożsamości może być również określona na zasadzie per-host w pliku konfiguracyjnym. Możliwe jest posiadanie wielu -iopcji (i wielu tożsamości określonych w plikach konfiguracyjnych).

Czy istnieje podobny sposób na określenie, gitktórego pliku klucza prywatnego użyć w systemie z wieloma kluczami prywatnymi w ~/.sshkatalogu?



Odpowiedzi:


671

W ~/.ssh/configdodaj:

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

Teraz możesz zrobić git clone git@github.com:username/repo.git.

UWAGA: Sprawdź, czy uprawnienia do IdentityFile wynoszą 400. SSH odrzuci, w sposób nieokreślony, klucze SSH, które są zbyt czytelne. Będzie to wyglądało jak odrzucenie poświadczenia. Rozwiązaniem w tym przypadku jest:

chmod 400 ~/.ssh/id_rsa_github

117
Co jeśli musisz połączyć się z tym samym hostem za pomocą różnych kluczy?
— Valentin Klinghammer

6
@Quelltextfabrik - możesz dodać kolejną sekcję z innym Gospodarzem: nerderati.com/2011/03/…
— Ben Challenor

1
@Cliff Nie, na mojej stronie podręcznika: „ HostName: Określa prawdziwą nazwę hosta, na który należy się zalogować. Można jej użyć do określenia pseudonimów lub skrótów dla hostów.” Moja wersja ssh to openssh-6.7p1.
— Grissiom

11
Jeśli plik konfiguracyjny jest nowy, nie zapomnij zrobićchmod 600 ~/.ssh/config
— elysch

2
@ValentinKlinghammer odpowiedź od @Flimm ma rozwiązanie tego pytania. Używa core.sshCommandkonfiguracji git. superuser.com/a/912281/162466
— VasyaNovikov

345

Zmienna środowiskowa GIT_SSH_COMMAND:

Z Gita w wersji 2.3.0 możesz używać zmiennej środowiskowej w GIT_SSH_COMMANDnastępujący sposób:

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

Pamiętaj, że -iczasem plik konfiguracyjny może go zastąpić. W takim przypadku należy podać SSH pusty plik konfiguracyjny, taki jak ten:

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

Konfiguracja core.sshCommand:

W Git w wersji 2.10.0 możesz to skonfigurować na 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

1
Musiałem wyeksportować powłoki zmiennej do zmiennej środowiskowej do tej pracy, to znaczy export GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_example", następniegit clone example
— Abdull

7
@ Abdull W Bash, wykonanie przypisania w tym samym wierszu, co polecenie, eksportuje zmienną środowiskową tylko dla tego polecenia. Wypróbuj: example=hello /usr/bin/env | grep example.
— Flimm

3
sytuacja stała się jeszcze lepsza: od Gita 2.10 możesz przechowywać polecenie w konfiguracji Gita: stackoverflow.com/a/38474220/520162
— eckes

2
@ Noitidart /dev/nulljest prawidłową nazwą pliku w systemach operacyjnych typu UNIX, nie działa w systemie Windows.
— Flimm

2
Dla mnie GIT_SSH_COMMANDnie działa, aż kiedyś IdentitiesOnly, jak tego polecenia: GIT_SSH_COMMAND="ssh -i ~/.ssh/mysubdir/id_rsa -o 'IdentitiesOnly yes'" git push.
— Tyler Collier

111

Nie ma bezpośredniego sposobu na określenie, gitktórego klucza prywatnego użyć, ponieważ polega on sshna uwierzytelnianiu repozytorium. Istnieje jednak kilka sposobów na osiągnięcie celu:

Opcja 1: ssh-agent

Możesz użyć ssh-agentdo tymczasowej autoryzacji swojego 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 przy użyciu GIT_SSH_COMMANDzmiennej środowiskowej (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 jednym wierszu - zignoruj $i pomiń \.

Opcja 3: GIT_SSH

Przekaż argumenty ssh za pomocą GIT_SSHzmiennej środowiskowej, aby określić alternatywny sshplik binarny.

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 wiersze poleceń powłoki (terminala), które należy wkleić do terminala. Utworzą plik o nazwie ssh, sprawią, że będzie wykonywalny i (pośrednio) go uruchomią.

Uwaga: GIT_SSHjest dostępny od wersji 0.9.4 (2005).

Opcja 4: ~/.ssh/config

Użyj ~/.ssh/configpliku zgodnie z sugestią zawartą w innych odpowiedziach, aby określić lokalizację klucza prywatnego, np

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

1
// Co się stanie, jeśli Twoja tożsamość w ssh-agent zostanie przekazana, jak w tym pytaniu? superuser.com/questions/971732/…
— Nathan Basanese

1
Pozwoliłem, że sformatuję ten post: IMO to zdecydowanie najbardziej wyczerpująca odpowiedź. W pierwotnym projekcie szybki skan zasugerował post, w którym opisałem jedno skomplikowane rozwiązanie problemu, więc go przegapiłem.
— Alberto

3
$ ssh-agent sh -c 'ssh-add ~/.ssh/id_rsa; git fetch user@host'pracował dla mnie, gdy nic innego by nie działało. Sława.
— Daniel Dewhurst,

1
Musiałem użyć ~/.ssh/configmetody, wariacje env nie działały dla mnie ...
— Greg Dubicki,

1
GIT_SSHjest dostępna od wersji 0.9.4 (sierpień 2005) , więc w zasadzie od czasu istnienia Git (kwiecień 2005)
— Dominik

32

Napisz skrypt, który wywołuje sshżądane argumenty, i umieść w nim nazwę pliku skryptu $GIT_SSH. Lub po prostu wprowadź swoją konfigurację ~/.ssh/config.


2
Kolejne wyjaśnienie, jak to zrobić.
— Sithsu

1
~/.ssh/configTo jest najlepsza droga.
— hek2mgl

Pracuję na komputerze (A), z którego wysyłam push na serwer (B), który akceptuje tylko uwierzytelnianie za pomocą klucza ssh. Chociaż moja konfiguracja ~ / .ssh / config na (A) działa idealnie dobrze, gdy pracuję bezpośrednio na tym komputerze, nie działa, gdy loguję się z innej lokalizacji (C). Użycie $GIT_SSHi skrypt rozwiązały ten problem. Dzięki!
— bsumirak

18

Jeśli nie chcesz określać zmiennych środowiskowych za każdym razem, gdy uruchamiasz git, nie chcesz innego skryptu opakowania, nie uruchamiaj / nie możesz uruchomić ssh-agent (1), ani nie chcesz pobierać innego pakietu tylko do tego celu, użyj git -remote-ext (1) transport zewnętrzny:

$ 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ż:

  • Jest to specyficzne dla repozytorium / zdalnego
  • Unikaj wzdęcia skryptu opakowania
  • Nie potrzebujesz agenta SSH - przydatne, jeśli chcesz bezobsługowych klonów / push / pullów (np. W cronie)
  • Zdecydowanie nie potrzeba zewnętrznego narzędzia

2
Ta odpowiedź była dokładnie tym, czego potrzebowałem, aby zmusić gitzasoby szefa kuchni do używania kluczy wdrażania specyficznych dla repozytorium do klonowania / pobierania z prywatnych repozytoriów Github. Dodatkową zaletą tej metody w porównaniu z metodami opartymi na środowisku / skrypcie jest to, że ponieważ ścieżka klucza jest zakodowana w konfiguracji repozytorium roboczego, użyje tego samego klucza zarówno podczas początkowego klonowania, jak i kolejnych operacji pobierania / wypychania.
— Adam Franco,

2
ŁAŁ! To jest po prostu świetne, nie wiedziałem o tym. Dzięki za odpowiedź, również bardzo pomocną w środowiskach marionetkowych, aby uniknąć dodatkowych kłopotów z zarządzaniem .ssh/configitp. +1!
— gf_

1
To rozwiązanie nie działa razem z flagą --recursive. Podmoduły nie są pobierane przy użyciu określonego klucza i dlatego zawodzą, jeśli wymagają uwierzytelnienia.
— Daniele Testa,

1
Każdy podmoduł jest zupełnie innym repozytorium, z własnym zestawem pilotów. Dla wygody są one sklejone ze sobą przez Git, ale w żaden sposób piloty do submodułu nie są powiązane z tymi w repozytorium nadrzędnym. Obawiam się, że musisz ustawić pilota za pomocą exttransportu w każdym podmodule, aby rekursja w obiekcie nadrzędnym działała.
— flaviovs

2
Jeśli wystąpi następujący błąd fatal: transport 'ext' not allowed, musisz dodać protokół ext do białej listy za pośrednictwem export GIT_ALLOW_PROTOCOL=ext. Zasadniczo pomocnik zdalnego git-remote-ext (który obsługuje adresy URL „ext :: ssh example.com% S foo / repo”) pozwala na wykonanie dowolnego polecenia. Zwykle nie stanowi to problemu, ponieważ użytkownik zawsze widzi adres URL przekazywany do git i ufa mu. Jednak podmoduły git za pośrednictwem pliku .gitmodules pozwalają osobie atakującej poprosić klienta o pobranie dowolnych adresów URL git. hackerone.com/reports/104465
— Gomino

18

Użyj niestandardowej konfiguracji hosta w ~/.ssh/confignastępujący sposób:

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

użyj niestandardowej nazwy hosta w ten sposób:

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

2
Oto odpowiedź, której szukałem, ponieważ mam osobne konta GitHub do domu i pracy. Musiałem tylko ustawić Host work.github.com HostName github.com IdentityFile ~/.ssh/work, a następnie zastąpić „github.com” słowem „work.github.com” za każdym razem, gdy klonuję repozytorium pracy. Nadal łączy się z „github.com”, ale używa innej niż domyślna pary kluczy.
— Mikkel

1
Adres URL szczegółów („ itblog.study.land / ...” ) już nie działa :(
— Carl Smotricz

@CarlSmotricz oryginał został przeniesiony tutaj: medium.com/@thucnc/…
— thucnguyen

4
WRESZCIE!!! Ta odpowiedź pokazuje, jak możesz wykorzystać to, co umieściłeś w ~/.ssh/configpliku. Każda inna odpowiedź pomija sposób ustawienia hosta podczas dodawania źródła, co automatycznie pozwala gitowi na użycie poprawnego pliku klucza. DZIĘKUJĘ CI!!
— BrianVPS,

1
Fajnie, właśnie tego szukałem :)
— Lucas D'Avila

15

Po moich zmaganiach $GIT_SSHchciałbym podzielić się tym, co dla mnie zadziałało.

Poprzez moje przykłady założę, że masz swój prywatny klucz na/home/user/.ssh/jenkins

Błąd, którego należy unikać: wartość GIT_SSH obejmuje opcje

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

lub cokolwiek podobnego zawiedzie, ponieważ git spróbuje wykonać wartość jako plik . Z tego powodu musisz utworzyć skrypt.

Przykład roboczy 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 działający skrypt może wyglądać następująco:

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

Zwróć uwagę $*na koniec, jest to ważna jego część.

Jeszcze bezpieczniejszą alternatywą, która zapobiegłaby wszelkim możliwym konfliktom z czymkolwiek w domyślnym pliku konfiguracyjnym (oraz wyraźnym wskazaniem portu, którego należy użyć) byłoby:

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

Zakładając, że skrypt jest włączony /home/user/gssh.sh, należy:

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

i wszystko zadziała.


Dzięki. Uwaga: użyj argumentu „$ @” zamiast $ * dla argumentów przekazywanych, ponieważ ten pierwszy zachowuje się poprawnie, gdy argumenty zawierają spacje.
— Piotr Findeisen

@PiotrFindeisen Dzięki za notatkę. Jednak nie rozumiem tego całkowicie - w zsh pomaga mi utrzymać ciągi z odstępem w jednym kawałku, ale w bash nie. Czy możesz mi powiedzieć coś więcej lub wskazać jakieś wyjaśnienie? Nie chcę dodawać modyfikacji na ślepo.
— Jan Vlcinsky

Powinieneś usunąć pierwszą połowę swojej odpowiedzi. Nikt nie jest zainteresowany rozwiązaniem, które nie działa, a jego zmarnowane czytanie, które zaciemnia poprawną odpowiedź na dole, co działa cudownie.
— Cerin,

@Cerin Jeśli masz na myśli usunięcie „Błąd unikania”, zamierzam go tam zachować. Dzieli się wspólną pułapkę, której należy unikać i jest bardzo krótka. Jestem pewien, że ktoś spróbuje zoptymalizować rozwiązanie, podając wszystkie rzeczy w zmiennej (tak mi się zdarzyło), więc starałem się skrócić ścieżkę do sukcesu.
— Jan Vlcinsky

5

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

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

Ładuje klucze ssh na żądanie, gdy są potrzebne po raz pierwszy, nawet przy wielu sesjach logowania, xterms lub współdzielonych domach NFS.

Mały plik konfiguracyjny umożliwia automatyczne ładowanie różnych kluczy i oddzielanie ich w różnych agentach (do przekazywania agentów) w zależności od tego, co musisz zrobić.


5

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

Moim rozwiązaniem było dodanie tego do mojego .zshrc / .bashrc:

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

Ilekroć chcę użyć git dla tego projektu, zastępuję „infogit” git:

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

Dla mnie łatwiej jest zapamiętać.


4

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

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

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

Następnie mam globalne ustawienie konfiguracji git:

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

I w dowolnym repozytorium git mogę po prostu ustawić lokalną ssh.identitywartość konfiguracji git:

$ 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 adresach e-mail, a następnie poprosić użytkownika user gain config. E-mail steruje wyborem klucza w następujący sposób ~/bin/git-ssh:

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

2

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

utwó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

wtedy, gdy musisz zmienić var ​​run:

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

Nie zapomnij o dodatkowej kropce !! to sprawia, że ​​skrypt ustawia zmienne środowisk !! --key i --port są opcjonalne.


2

Zasadniczo chcesz do tego użyć ~/.ssh/config. Po prostu sparuj adresy serwerów z kluczami, których chcesz użyć 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 ~/.ssh/id_rsajako domyślnego klucza do użycia.


2

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

W razie potrzeby utwórz nowy plik konfiguracyjny SSH ~/.ssh/configi zmień uprawnienia na 400

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

Dodaj to do ~/.ssh/configpliku:

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

Jeśli masz już zdalną konfigurację, możesz ją usunąć, w przeciwnym razie nadal możesz zostać poproszony o podanie nazwy użytkownika i hasła:

git remote rm origin

Następnie dodaj zdalny do repozytorium git i zauważ dwukropek przed nazwą użytkownika:

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

A następnie polecenia git działają normalnie, np .:

git push origin master
git pull origin 

@HeyWatch W tym wątku SO sugerowano dodanie, IdentitiesOnly yesaby zapobiec domyślnemu zachowaniu SSH wysyłania pliku tożsamości pasującego do domyślnej nazwy pliku dla każdego protokołu. Zobacz ten wątek, aby uzyskać więcej informacji i referencje.


To był mój błąd: „Jeśli masz już zdalną konfigurację ...”. Wielkie dzięki!!!
— Allan Andrade,

częsty błąd --- oto odpowiedź
— Goddard

1

Wystarczy użyć ssh-agenti ssh-addpoleceń.

# 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 poleceń możesz używać obu klawiszy jednocześnie. Po prostu wpisz

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

sklonować swoje repozytorium.

Musisz wykonać powyższe polecenie po ponownym uruchomieniu komputera.


Proszę wyjaśnić proces, w tym Jak mogę utworzyć agenta
— Srikrushna

0

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

  • Właśnie skopiowałem mój klucz prywatny do .ssh / id_rsa
  • ustaw uprawnienia na 600

I git automatycznie czyta klucz. Nic nie pytam i nie rzuca błędu. Po prostu działa dobrze.


Czy zauważyłeś, że pytanie dotyczy „systemu z wieloma kluczami prywatnymi w ~/.sshkatalogu”?
— Scott

0

Chociaż pytanie nie wymaga tego, zamieszczam tę odpowiedź dla każdego, kto chce rozwiązać ten sam problem tylko dla .

Rozwiązanie gitlab

Próbowałem użyć podejścia do , ale nawet dokumentacja git zaleca używanie ~/.ssh/configczegoś więcej niż prostego przypadku. W moim przypadku serwer - i chciałem to zrobić jako określony użytkownik - który jest oczywiście definiowany przez podczas a nie nazwę użytkownika git. Po wdrożeniu po prostu wykonuję następujące czynności:

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

Ustawiać

Przypomnij sobie lokalizację twojego /myfolder/.ssh/my_gitlab_id_rsa w moim przypadku.

Dodaj wpis w ~/.ssh/config:

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

Dodaj w ~/.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"

Jako bonus wykonuję swoje zatwierdzenia na tym samym hoście jako określony użytkownik za pomocą tego :

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

Wyjaśnienie

Wszystkie powyższe zakłada, że ​​odpowiedni pilot jest, origina odpowiedni oddział jest obecnie sprawdzony. W celach informacyjnych natknąłem się na kilka elementów, które należało rozwiązać:

  • Rozwiązanie wymaga utworzenia nowego pilota gitlab_as_mei nie podobało mi się widzenie dodatkowego pilota wiszącego w moim drzewie dziennika, więc usuwam go po zakończeniu
  • Aby utworzyć pilota, trzeba wygenerować adres URL pilota w locie - w przypadku gitlab zostało to osiągnięte za pomocą prostego bash
  • Wykonując push do gitlab_as_me, musisz dokładnie określić, którą gałąź naciskasz
  • Po wykonaniu wypychania originwskaźnik lokalny musi zostać „zaktualizowany” w celu dopasowania gitlab_as_me( git pull origin $branchrobi to)

0

Jeśli masz wiele kont git i chcesz mieć inny klucz ssh

Musisz wykonać ten sam krok, aby wygenerować klucz ssh, ale upewnij się, że tak

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

Wprowadź ścieżkę, którą chcesz zapisać (np. My-pc / Desktop / .ssh / ed25519)

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

Musisz do nowej tożsamości ssh za pomocą poniższego polecenia

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

(1) Cytujesz kogoś czy coś? Jeśli tak, proszę podać źródło. Jeśli nie, nie używaj formatowania cytatów. (2) Co to jest „ed25519”? …………………………… Proszę nie odpowiadać w komentarzach; edytuj  swoją odpowiedź, aby była jaśniejsza i bardziej kompletna.
— Scott

0
    # 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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.