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

Odpowiedź Randala Schwartza prawie mi pomogła. 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 OpenSSH man . uwaga: niektóre z wymienionych słów kluczowych mogą być już obecne w pliku /etc/ssh/ssh_config.

Możesz poinstruować ssh, aby wypróbował kilka 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 jakim serwerem. Użyje tylko pierwszego działającego klucza.

Również można wprowadzić hasło tylko wtedy, gdy dany serwer jest gotów zaakceptować klucz. Jak widać powyżej ssh nie próbował prosić o hasło dla .ssh/id_rsa, nawet jeśli je posiadał.

Na pewno nie prześciga konfiguracji na serwer jak w innych odpowiedziach, ale przynajmniej ty nie musisz dodawać konfiguracji dla wszystkich i każdego serwera, z którym się łączysz!

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

Upewnij się, że przetestujesz go przed dodaniem z:

ssh -i ~/.ssh/xxx_id_rsa [email protected]

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

chmod 0600 ~/.ssh/xxx_id_rsa

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

Załóżmy, że nazwa użytkownika Twojego konta GitHub firmy to abc1234 . Załóżmy, że nazwa użytkownika twojego konta na Githubie to jack1234

I załóżmy, że stworzyłeś dwa klucze RSA, a mianowicie id_rsa_company i id_rsa_personal. Tak więc Twój plik konfiguracyjny będzie wyglądał następująco:

# 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, kiedy klonujesz repozytorium (nazwa demo) Z firmowego konta GitHub, adres URL repozytorium będzie wyglądał następująco:

Repo URL: [email protected]:abc1234/demo.git

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

git@company:abc1234/demo.git

Zauważ jak github.com jest teraz zastąpiony aliasem "firma", jak zdefiniowaliśmy w plik konfiguracyjny.

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

Zgadzam się z Tuomasem co do używania SSH-agenta. Chciałem również dodać drugi klucz prywatny do pracy i ten tutorial zadziałał jak urok dla mnie.

Kroki są następujące:

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key e. g ssh-add ~/.ssh/id_rsa
3. zweryfikuj przez $ ssh-add -l
4. Przetestuj z $ssh -v <host url> np ssh -v [email protected]

1. Wygeneruj klucz SSH:

   $ ssh-keygen -t rsa -C <[email protected]>
   

2. Wygenerować another SSH key:

   $ ssh-keygen -t rsa -f ~/.ssh/accountB -C <[email protected]>
   

   Teraz dwa klucze publiczne (id_rsa.pub, accountB.pub ) powinien istnieć w katalogu ~/.ssh/.

   $ ls -l ~/.ssh     # see the files of '~/.ssh/' directory 
   

3. Utwórz plik konfiguracyjny ~/.ssh/config o 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. Klon z default konta.

   $ git clone [email protected]:username/project.git
   

5. Klon z accountB konta.

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

Zobacz Więcej Proszę.

Użyj ssh-agent dla kluczy.

Napotkałem ten problem jakiś czas temu, kiedy miałem dwa konta Bitbucket i chciałem przechowywać oddzielne klucze SSH dla obu. To mi się udało.

Utworzyłem dwie oddzielne 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, kiedy musiałem sklonować repozytorium z mojego konta roboczego-polecenie było następujące.

git clone [email protected]:teamname/project.git

Musiałem zmodyfikować to polecenie do:

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

Podobnie polecenie klonowania z mojego konta osobistego musiało zostać zmodyfikowane do

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

Zobacz ten link aby uzyskać więcej informacji.

Teraz, w najnowszej wersji git, możemy określić sshCommand w pliku konfiguracyjnym git.

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

Ważne: musisz uruchomić ssh-agent

Przed użyciem ssh-add należy uruchomić ssh-agent (jeśli nie jest już uruchomiony) 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.

Możesz utworzyć plik konfiguracyjny o nazwie config w folderze ~/.ssh. Może zawierać:

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

To pozwoli Ci połączyć się z takimi maszynami

 ssh aws

Na Centos 6.5 z openssh_5. 3P1, OpenSSL 1.0.1 e-fips, rozwiązałem problem zmieniając nazwy moich plików kluczy tak, że żaden z nich nie miał domyślnej nazwy. Ojej .katalog SSH zawiera id_rsa_foo i id_rsa_bar ale nie ma id_rsa itp.