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.