Najlepszy sposób na użycie wielu kluczy prywatnych SSH na jednym kliencie


869

Chcę używać wielu kluczy prywatnych do łączenia się z różnymi serwerami lub różnymi częściami tego samego serwera (moje zastosowania to administracja systemem serwera, administracja Git i normalne użycie Git na tym samym serwerze). Próbowałem po prostu ułożyć klucze w id_rsaplikach bezskutecznie.

Najwyraźniej najprostszym sposobem na zrobienie tego jest użycie polecenia

ssh -i <key location> login@server.example.com 

To dość kłopotliwe.

Wszelkie sugestie, jak zrobić to trochę łatwiej?


1
Napisałem ten artykuł, który szczegółowo opisuje różne konfiguracje i ich siłę / wady.
Raffi

Odpowiedzi:


1233

Od mojego .ssh/config:

Host myshortname realname.example.com
    HostName realname.example.com
    IdentityFile ~/.ssh/realname_rsa # private key for realname
    User remoteusername

Host myother realname2.example.org
    HostName realname2.example.org
    IdentityFile ~/.ssh/realname2_rsa  # different private key for realname2
    User remoteusername

I tak dalej.


24
Dzięki Randal! Zrobiłem trochę kopania w .ssh / config i znalazłem to: github.com/guides/multiple-github-accounts Wskazał mi właściwy kierunek.
Justin

6
To była świetna pomoc (oprócz stackoverflow.com/a/3828682/169153 ). Jeśli chcesz użyć kluczy do szpachli, postępuj zgodnie z tym dokumentem tutaj: blog.padraigkitterick.com/2007/09/16/…
Urda

2
Uważam ten post za bardzo pomocny. Jednym błędem, który popełniłem podczas tworzenia pliku konfiguracyjnego było umieszczenie pliku .txt w folderze .ssh zamiast uruchamiania polecenia „touch”, aby utworzyć plik konfiguracyjny.
M_x_r 22.12.12

53
Zauważ, że możesz również określić wiele IdentityFilewpisów dla tego samego Host, które są następnie sprawdzane w kolejności podczas łączenia.
sschuberth

12
Służy IdentitiesOnly yesdo zapobiegania ~ / .ssh / id_rsa lub innym tożsamościom. (To była pierwotnie edycja)
user3338098,

369

Możesz poinstruować ssh, aby spróbował wielu kluczy po kolei podczas łączenia. Oto jak:

$ cat ~/.ssh/config
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_old
IdentityFile ~/.ssh/id_ed25519
# ... and so on

$ ssh server.example.com -v
....
debug1: Next authentication method: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa_old
debug1: read PEM private key done: type RSA
....
[server ~]$

W ten sposób nie musisz określać, który klucz działa z którym serwerem. Użyje tylko pierwszego działającego klucza.

Można również wprowadzić hasło tylko wtedy, gdy dany serwer jest skłonny zaakceptować klucz. Jak widać powyżej ssh nie próbował poprosić o hasło, .ssh/id_rsanawet jeśli je posiadało.

Na pewno nie wyprzedza konfiguracji na serwer jak w innych odpowiedziach, ale przynajmniej nie będziesz musiał dodawać konfiguracji dla wszystkich serwerów, z którymi się łączysz!


12
To fantastyczne rozwiązanie dla zadanego pytania, ale nie do końca zaspokajające potrzeby, które zamierzał zadać pytający. Dla mnie było to dokładnie właściwe rozwiązanie i doskonale spełnia potrzebę „Najlepszego sposobu używania wielu kluczy prywatnych SSH na jednym kliencie”.
Wade

2
Nie wydaje się, aby działało to w deklaracji hosta w pliku konfiguracyjnym
Maksim Luzik,

29
Nie działa to dobrze z git, ponieważ jeśli masz dwa klucze wdrażania github, pierwszy z listy jest prawidłowy i będzie działał, ale wtedy github będzie narzekał, że repozytorium nie pasuje.
Adam Reis,

Jest to podejście bardziej dynamiczne, świetnie sprawdza się w niektórych sytuacjach. Dzięki za to
gbolo

7
Pamiętaj, jeśli masz coś takiego jak fail2ban na tych serwerach. Możesz skończyć w jednym z tych więzień ... z powodu nieudanych prób wygenerowanych przez inne klucze ...
Piccolo,

254

Odpowiedź od Randal Schwartz prawie pomógł mi przez całą drogę. Mam inną nazwę użytkownika na serwerze, więc musiałem dodać słowo kluczowe User do mojego pliku:

Host           friendly-name
HostName       long.and.cumbersome.server.name
IdentityFile   ~/.ssh/private_ssh_file
User           username-on-remote-machine

Teraz możesz połączyć się, używając przyjaznej nazwy:

ssh friendly-name

Więcej słów kluczowych można znaleźć na stronie podręcznika OpenSSH . UWAGA: Niektóre z wymienionych słów kluczowych mogą już być obecne w pliku / etc / ssh / ssh_config .


Jeśli się nie mylę, użytkownik zazwyczaj podajesz bezpośrednio w
adresie

3
Wolę również użyć słowa kluczowego „Port”. Innym interesującym słowem kluczowym jest „StrictHostKeyChecking”.
Ethan

120

Poprzednie odpowiedzi poprawnie wyjaśniły sposób utworzenia pliku konfiguracyjnego do zarządzania wieloma kluczami ssh. Myślę, że ważną rzeczą, którą również należy wyjaśnić, jest zastąpienie nazwy hosta nazwą aliasu podczas klonowania repozytorium .

Załóżmy, że nazwa użytkownika konta GitHub Twojej firmy to abc1234 . Załóżmy, że nazwa twojego osobistego konta GitHub to jack1234

Załóżmy, że utworzono dwa klucze RSA, a mianowicie id_rsa_company i id_rsa_personal . Twój plik konfiguracyjny będzie wyglądał jak poniżej:

# Company account
Host company
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company

# Personal account
Host personal
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_personal

Teraz, gdy klonujesz repozytorium (o nazwie demo) z firmowego konta GitHub, adres URL repozytorium będzie podobny do:

Repo URL: git@github.com:abc1234/demo.git

Teraz robiąc to git clone, powinieneś zmodyfikować powyższy adres URL repozytorium jako:

git@company:abc1234/demo.git

Zauważ, jak github.com jest teraz zamieniany na alias „firma”, jak zdefiniowaliśmy w pliku konfiguracyjnym.

Podobnie musisz zmodyfikować sklonowany adres URL repozytorium na koncie osobistym w zależności od aliasu podanego w pliku konfiguracyjnym.


10
Chciałbym móc jeszcze raz głosować za odpowiedzią ... jest to właściwy sposób podejścia do problemu i jest on bezpieczniejszy i szybszy niż inne opcje. Również bardziej skalowalny (pozwala na zdefiniowanie różnych kluczy dla tej samej nazwy hosta)
Guyarad

4
Nie marnuj więcej czasu, oto odpowiedź. Wielkie dzięki.
Luis Milanese

2
Naprawdę chciałbym znaleźć tę odpowiedź wcześniej ... ale lepiej późno niż wcale, dziękuję bardzo!
Hildy,

2
Świetne wyjaśnienie! Działa idealnie dla mnie. A jeśli zapomniałeś sklonować repozytorium za pomocą aliasu, często możesz później edytować zdalny adres URL pochodzenia.
tkahn

1
płać tylko za uwagę, ponieważ plik konfiguracyjny musi być (chmod 600)
Christiano Matos

105
foo:~$ssh-add ~/.ssh/xxx_id_rsa

Pamiętaj, aby go przetestować przed dodaniem za pomocą:

ssh -i ~/.ssh/xxx_id_rsa username@example.com

Jeśli masz jakieś problemy z błędami, czasami zmiana bezpieczeństwa pliku pomaga:

chmod 0600 ~/.ssh/xxx_id_rsa

4
To moim zdaniem najbardziej zwięzłe i eleganckie rozwiązanie. Działa jak urok!
artur

@ Bobo możesz umieścić go w swoim bashrc lub bash_profile (lub cokolwiek, co jest odpowiednikiem Maca)?
T0xicCode

6
+1 dla chmod 0600 - problemy z uprawnieniami uniemożliwiały mi połączenie
amacy

Dla mnie działał jak urok (i nie zapomnij o 0600 permsach).
Dmytro Uhnichenko

1
Przyszedł z Ubuntu na Maca i właśnie tego potrzebowałem.
hariom

42
  1. Wygeneruj klucz SSH:

    $ ssh-keygen -t rsa -C <email1@example.com>
    
  2. Generuj another SSH key:

    $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <email2@example.com>
    

    Teraz w katalogu powinny znajdować się dwa klucze publiczne ( id_rsa.pub , accountB.pub ) ~/.ssh/.

    $ ls -l ~/.ssh     # see the files of '~/.ssh/' directory 
    
  3. Utwórz plik konfiguracyjny ~/.ssh/configo następującej treści:

    $ nano ~/.ssh/config
    
    Host bitbucket.org  
        User git  
        Hostname bitbucket.org
        PreferredAuthentications publickey  
        IdentityFile ~/.ssh/id_rsa  
    
    Host bitbucket-accountB  
        User git  
        Hostname bitbucket.org  
        PreferredAuthentications publickey  
        IdentitiesOnly yes  
        IdentityFile ~/.ssh/accountB  
    
  4. Klonuj z defaultkonta.

    $ git clone git@bitbucket.org:username/project.git
    
  5. Klonuj z accountBkonta.

    $ git clone git@bitbucket-accountB:username/project.git
    

Zobacz więcej tutaj


24

Zgodziłbym się z Tuomasem na temat korzystania z ssh-agent. Chciałem również dodać drugi klucz prywatny do pracy i ten samouczek działał dla mnie jak urok.

Kroki są jak poniżej:

  1. $ ssh-agent bash
  2. $ ssh-add /path.to/private/key na przykład ssh-add ~/.ssh/id_rsa
  3. Zweryfikuj przez $ ssh-add -l
  4. Przetestuj za pomocą $ssh -v <host url>npssh -v git@assembla.com

4
Po wykorzystaniu ssh-agentprzez lata, ja niedawno włączony do korzystania gnoma gnome-keyringw moim i3WM. Powód jest prosty: menedżer kluczy Gnome automagicznie obsługuje dodawanie i usuwanie kluczy ssh bez konieczności pamiętania o tym ssh-add. Ponadto zapewniam jedno hasło do ich odblokowania (i dla określonego czasu przekroczenia limitu czasu). Do każdej jego własności. Ponieważ używam ustawień gnome w Arch, było to plug and play z moją konfiguracją. Jeśli jesteś anty-gnomem, zignoruj ​​ten komentarz.
eduncan911

@ eduncan911, zgadzam się, że breloczek do gnome może być pomocny, ale tak naprawdę nie obsługuje kluczy ed25519, więc dla mnie to nie jest starter. Aktualizacja: z wiki.archlinux.org/index.php/GNOME/... widzę , że teraz używa on ssh-agent systemu, więc nie jest to już problemem.
Brian Minton,

15

Natrafiłem na ten problem jakiś czas temu, kiedy miałem dwa konta Bitbucket i chciałem przechowywać osobne klucze SSH dla obu. To działało dla mnie.

Utworzyłem dwie osobne konfiguracje ssh w następujący sposób.

Host personal.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/personal
Host work.bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile /Users/username/.ssh/work

Teraz, gdy musiałem sklonować repozytorium z mojego konta służbowego - polecenie było następujące.

git clone git@bitbucket.org:teamname/project.git

Musiałem zmodyfikować to polecenie, aby:

git clone git@**work**.bitbucket.org:teamname/project.git

Podobnie polecenie klonowania z mojego konta osobistego musiało zostać zmienione na

git clone git @ personal .bitbucket.org: name / personalproject.git

Zobacz ten link, aby uzyskać więcej informacji.



11

Teraz, dzięki najnowszej wersji git, możemy określić sshCommand w specyficznym dla repozytorium pliku konfiguracyjnym git.

  [core]
      repositoryformatversion = 0
      filemode = true
      bare = false
      logallrefupdates = true
      sshCommand = ssh -i ~/.ssh/id_rsa_user   
   [remote "origin"]
      url = git@bitbucket.org:user/repo.git
      fetch = +refs/heads/*:refs/remotes/origin/*

1

WAŻNE: Musisz uruchomić ssh-agent

Musisz uruchomić ssh-agent (jeśli jeszcze nie działa) przed użyciem ssh-add w następujący sposób:

eval `ssh-agent -s` # start the agent

ssh-add id_rsa_2 # where id_rsa_2 is your new private key file

Zauważ, że polecenie eval uruchamia agenta w GIT bash w systemie Windows. Inne środowiska mogą użyć wariantu do uruchomienia agenta SSH.


1

Możesz utworzyć plik konfiguracyjny o nazwie configw swoim ~/.sshfolderze. Może zawierać:

Host aws
    HostName *yourip*
    User *youruser*
    IdentityFile *idFile*

Umożliwi to połączenie się z takimi maszynami

 ssh aws

1

Na Ubuntu 18.04 nie ma nic do roboty.

Po pomyślnym utworzeniu drugiego klucza ssh system spróbuje znaleźć pasujący klucz ssh dla każdego połączenia.

Żeby było jasne, możesz utworzyć nowy klucz za pomocą tych poleceń

# generate key make sure you give it a new name (id_rsa_server2)
ssh-keygen 
# make sure ssh agent is running
eval `ssh-agent`
# add the new key
ssh-add ~/.ssh/id_rsa_server2
# get the public key to add it to a remote system for authentication
cat ~/.ssh/id_rsa_server2.pub

1

Wiele par kluczy w GITHUB

1.0 PLIK KONFIGURACJI SSH

1.1 UTWÓRZ ~ / .ssh / config

1.2 chmod 600 ~ / .ssh / config (MUST)

1.3 wprowadź następujące dane do pliku:

Host pizza

HostName github.com

PreferredAuthentications publickey # opcjonalny

IdentityFile ~ / .ssh / privatekey1

Przypadek A: FRESH NEW GIT CLONE

użyj tego polecenia, aby git clone:

$ git clone git @ pizza: twojgitusername / pizzahut_repo.git

Uwaga: Jeśli chcesz w przyszłości zmienić nazwę hosta „pizza” .ssh / config, przejdź do sklonowanego folderu git, edytuj wiersz adresu URL pliku .git / config (patrz przypadek B)

Przypadek B: JUŻ FOLDER GIT CLONE

2.1 przejdź do sklonowanego folderu, a następnie przejdź do folderu .git

2.2 edycja pliku konfiguracyjnego

2.3 zaktualizuj adres URL ze starego na nowy:

(Old) url = git@github.com:yourgitusername/pizzahut_repo.git    

(New) url = git@pizza:yourgitusername/pizzahut_repo.git


1

dla mnie jedynym działającym rozwiązaniem było po prostu dodanie ~/.ssh/config

Host *
  IdentityFile ~/.ssh/your_ssh_key
  IdentityFile ~/.ssh/your_ssh_key2
  IdentityFile ~/.ssh/your_ssh_key3
  AddKeysToAgent yes

your_ssh_key jest bez żadnego rozszerzenia, nie używaj .pub


0

Na Centos 6.5 z OpenSSH_5.3p1, OpenSSL 1.0.1e-fips rozwiązałem problem, zmieniając nazwę moich plików kluczy, aby żaden z nich nie miał domyślnej nazwy. Mój katalog .ssh zawiera id_rsa_foo i id_rsa_bar, ale nie ma id_rsa itp.


I w jaki sposób wykorzystywane są klucze? Czy jest jakieś automatyczne wykrywanie?
robsch

Zobacz odpowiedź Randala Schwartza, aby dowiedzieć się, jak wybrać właściwy klucz dla danego hosta stackoverflow.com/questions/2419566/…
Chris Owens

0

Jak wspomniano na stronie blogu atlassian, wygeneruj konfigurację w .ssh zawierającą następujący tekst:

#user1 account
 Host bitbucket.org-user1
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user1
     IdentitiesOnly yes

 #user2 account
 Host bitbucket.org-user2
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user2
     IdentitiesOnly yes

Następnie możesz po prostu przejść do kasy z domeną sufiksów, aw ramach projektów możesz lokalnie skonfigurować nazwy autorów itp.


0

Możesz wypróbować ten pakiet sshmulti npm do obsługi wielu kluczy ssh.


Zdecydowanie polecam nie używać npm do czegoś takiego. Miał kaskadę zależności, które po krótkiej inspekcji obejmują szereg twórców samotnych wilków, kilkuletnie pakiety. Sama strona sshmulti npm deklaruje, że jest nieprzetestowana.
Jack Wasey

0

Oto rozwiązanie, którego użyłem inspirowane odpowiedzią @ sajib-khan. Domyślna konfiguracja nie jest ustawiona, to moje osobiste konto na gitlab, a inne określone to moje konto firmowe. Oto co zrobiłem:

Wygeneruj klucz ssh

ssh-keygen -t rsa -f ~/.ssh/company -C "name.surname@company.com"

Edytuj konfigurację ssh

nano ~/.ssh/config

    Host company.gitlab.com
    HostName gitlab.com
    PreferredAuthentications publickey  
    IdentityFile ~/.ssh/company

Usuń buforowane klucze ssh

ssh-add -D

Sprawdź to !

ssh -T git@company.gitlab.com

Witamy w GitLab, @ hugo.sohm!

ssh -T git@gitlab.com

Witamy w GitLab, @HugoSohm!

Użyj tego !

Konto firmowe

$ git clone git@company.gitlab.com:group/project.git

Konto osobiste / domyślne

$ git clone git@gitlab.com:username/project.git

Oto źródło , którego użyłem, mam nadzieję, że to pomoże!


0

Podoba mi się podejście do ustawiania następujących parametrów w ~ / .ssh / config:

# Config for Github to support multiple Github keys
Host  github.com
  HostName github.com
  User git
# UseKeychain adds each keys passphrase to the keychain so you don't have to enter the passphrase each time.
  UseKeychain yes
# AddKeysToAgent would add the key to the agent whenever it is used, which might lead to debugging confusion since then sometimes the one repo works and sometimes the other depending on which key is used first.
#  AddKeysToAgent yes
# I only use my private id file so all private repos don't need the env var `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
  IdentityFile ~/.ssh/id_rsa

Następnie w repozytorium możesz utworzyć .envplik zawierający polecenie ssh, które będzie używane:

GIT_SSH_COMMAND="ssh -i ~/.ssh/your_ssh_key"

Jeśli następnie użyjesz np. Dotenv, środowisko var jest eksportowane automatycznie, a whoop whoop możesz określić klucz, który chcesz dla projektu / katalogu. Hasło jest proszone tylko raz, ponieważ jest dodawane do pęku kluczy.

To rozwiązanie działa idealnie z git i jest przeznaczone do pracy na komputerze Mac (z powodu UseKeychain).

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.