Лучший способ использовать несколько закрытых ключей SSH на одном клиенте

на ответ от Рэндала Шварца почти помог мне всю дорогу. У меня другое имя пользователя на сервере, поэтому мне пришлось добавить пользователей ключевое слово в моем файле:

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

теперь вы можете подключиться, используя понятное имя:

ssh friendly-name

больше ключевых слов можно найти на OpenSSH man page. Примечание: некоторые из перечисленных ключевых слов уже должен присутствовать в вашем в/etc/СШ/файле ssh_config.

вы можете поручить ssh попробовать несколько ключей подряд при подключении. Вот как:

$ 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 ~]$

таким образом, вам не нужно указывать, какой ключ работает с каким сервером. Он просто использует первый рабочий ключ.

Также вы введете только парольную фразу, Если данный сервер готов принять ключ. Как видно выше, ssh не пытался запросить пароль для .ssh/id_rsa даже если бы он был.

конечно, это не превосходит конфигурацию на сервере, как в других ответы, но, по крайней мере, вам не придется добавлять конфигурацию для всех и каждого сервера, к которому вы подключаетесь!

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

убедитесь, что вы проверить его перед добавлением с:

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

Если у вас возникли проблемы с ошибками, иногда изменение безопасности файла помогает:

chmod 0600 ~/.ssh/xxx_id_rsa

предыдущие ответы правильно объяснили способ создания файла конфигурации для управления несколькими ключами ssh. Я думаю, что важная вещь, которая также должна быть объяснена, - это замена имени хоста на псевдоним при клонировании репозитория.

Предположим, ваш компании GitHub является abc1234. И предположим, что ваш имя пользователя личного аккаунта GitHub-jack1234

и, предположим, у вас есть создал два ключа RSA, а именно id_rsa_company и id_rsa_personal. Итак, ваш конфигурация будет выглядеть следующим образом:

# 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

теперь, когда вы клонируете хранилище (по имени demo) из учетной записи GitHub компании URL-адрес репозитория будет выглядеть примерно так:

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

теперь, когда делаю git clone, вы должны изменить вышеуказанный URL репозитория как:

git@company:abc1234/demo.git

уведомления как github.com теперь заменяется псевдонимом "компания", как мы определили в файле конфигурации.

аналогично, вы должны изменить URL-адрес клона репозитория в личном кабинете в зависимости от псевдонима, предоставленного в файле конфигурации.

Я бы согласился с Туомасом об использовании SSH-агента. Я также хотел добавить второй закрытый ключ для работы и в этом уроке работал как шарм для меня.

шаги, как показано ниже:

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key Эл.г ssh-add ~/.ssh/id_rsa
3. Проверьте $ ssh-add -l
4. С $ssh -v <host url> Эл.г ssh -v git@assembla.com

1. создать SSH ключ:

   $ ssh-keygen -t rsa -C <email1@example.com>
   

2. создать another SSH key:

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

   теперь, два открытых ключей (id_rsa.паб, accountB.паб) следует есть в .

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

3. создать конфигурационный файл ~/.ssh/config следующего содержания:

   $ 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. клон от

используйте ssh-agent для ваших ключей.

я столкнулся с этой проблемой некоторое время назад, когда у меня было две учетные записи Bitbucket и хотел хранить отдельные ключи SSH для обоих. Это то, что сработало для меня.

Я создал две отдельные конфигурации ssh следующим образом.

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

Теперь, когда мне пришлось клонировать репозиторий из моей рабочей учетной записи - команда была следующей.

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

мне пришлось изменить эту команду на:

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

аналогично команда clone из моего личного кабинета имела изменить на

в Git клон git@персональный.тут Bitbucket.орг:имя/personalproject.ГИТ

Refer этой ссылке для получения дополнительной информации.

теперь, с последней версией git, мы можем указать sshCommand в определенный репозиторий файл git файл config.

  [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/*

важно: вы должны запустить ssh-agent

вы должны запустить ssh-agent (если он еще не запущен) перед использованием ssh-add следующим образом:

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

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

обратите внимание, что команда eval запускает агент на Git bash в windows. Другие среды могут использовать вариант для запуска агента SSH.

вы можете создать файл конфигурации с именем config в своем . Он может содержать:

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

Это позволит вам подключиться к машинам, как это

 ssh aws

на Centos 6.5 работает OpenSSH_5.3p1, OpenSSL 1.0.1 e-fips, я решил проблему, переименовав мои ключевые файлы, чтобы ни один из них не имел имени по умолчанию. Мой. каталог ssh содержит id_rsa_foo и id_rsa_bar, но не id_rsa и т. д.