Из моего .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

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

ssh myshortname

ssh myother

И так далее.

Вы можете указать 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, даже если он у него был.

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

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

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

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

ssh friendly-name

Другие ключевые слова можно найти на справочной странице OpenSSH. ПРИМЕЧАНИЕ. Некоторые из перечисленных ключевых слов могут уже присутствовать в вашем файле /etc/ssh/ssh_config.

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

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

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

# 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: [email protected]:abc1234/demo.git

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

git@company:abc1234/demo.git

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

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

ssh-add ~/.ssh/xxx_id_rsa

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

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

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

chmod 0600 ~/.ssh/xxx_id_rsa

1. Сгенерируйте SSH-ключ:

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

2. Создайте еще один ключ SSH:

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

   Теперь в каталоге ~/.ssh/ должны существовать два открытых ключа (id_rsa.pub, accountB.pub).

   $ 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. Клонировать с default аккаунта.

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

5. Клон с аккаунта accountB.

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

Подробнее здесь

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

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

1. $ ssh-agent bash
2. $ ssh-add /path.to/private/key e.g ssh-add ~/.ssh/id_rsa
3. Подтвердить от $ ssh-add -l
4. Проверьте это с помощью $ssh -v <host url>, например, ssh -v [email protected]

Я столкнулся с этой проблемой некоторое время назад, когда у меня было две учетные записи 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 [email protected]:teamname/project.git

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

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

Точно так же команду клонирования из моей личной учетной записи пришлось изменить на

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

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

Теперь, с последней версией Git, мы можем указать sshCommand в файле конфигурации 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/*

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

Вот решение, которое я использовал, вдохновленное ответом Саджиб-хана. Конфигурация по умолчанию не установлена; это моя личная учетная запись на GitLab, а другая указанная учетная запись — учетная запись моей компании. Вот что я сделал:

Сгенерируйте SSH-ключ

ssh-keygen -t rsa -f ~/.ssh/company -C "[email protected]"

Отредактируйте конфигурацию SSH

nano ~/.ssh/config

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

Удалить кешированные ключи SSH

ssh-add -D

Попробуй это!

ssh -T [email protected]

Добро пожаловать в GitLab, @hugo.sohm!

ssh -T [email protected]

Добро пожаловать в GitLab, @HugoSohm!

Используй это!

Аккаунт компании

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

Личная учетная запись / учетная запись по умолчанию

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

Вот источник что я использовал.

Для меня единственным рабочим решением было просто добавить это в файл ~/.ssh/config:

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

your_ssh_key без расширения. Не используйте .pub.

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

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

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

 ssh aws

Несколько пар ключей на GitHub

1.0 конфигурационный файл SSH

1.1 Создать ~/.ssh/config

1.2 chmod 600 ~/.ssh/config (обязательно)

1.3 Введите в файл следующее:

Хозяин пиццы

Имя хоста github.com

Открытый ключ PreferredAuthentications # необязательный

Файл идентификации ~/.ssh/privatekey1

Кейс A: Свежий новый клон Git

Используйте эту команду для клонирования Git:

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

Примечание. Если вы хотите изменить имя хоста «пицца» в .ssh/config в будущем, перейдите в клонированную папку Git, отредактируйте строку URL-адреса файла .git/config (см. случай B)

Случай B: папка клонирования Git уже есть

2.1 Перейдите в клонированную папку, а затем перейдите в папку .git

2.2 Редактировать файл конфигурации

2.3 Обновите URL-адрес со *старого на новый:

(Old) URL = [email protected]:yourgitusername/pizzahut_repo.git

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

Тем, кто работает с aws, я настоятельно рекомендую работа с Подключение экземпляра EC2.

Amazon EC2 Instance Connect предоставляет простой и безопасный способ подключения к вашим инстансам с помощью Secure Shell (SSH).

Благодаря EC2 Instance Connect вы используете политики и принципы AWS Identity and Access Management (IAM) для управления доступом SSH к своим инстансам, устраняя необходимость в совместном использовании ключей SSH и управлении ими.

После установки соответствующих пакетов (pip install ec2instanceconnectcli или непосредственного клонирования репозитория) < strong>вы можете очень легко подключиться к нескольким экземплярам EC2, просто изменив идентификатор экземпляра:

Что происходит за кулисами?

Когда вы подключаетесь к инстансу с помощью EC2 Instance Connect, API Instance Connect отправляет одноразовый открытый ключ SSH в метаданные инстанса, где он остается в течение 60 секунд. Политика IAM, прикрепленная к вашему пользователю IAM, разрешает вашему пользователю IAM передавать открытый ключ в метаданные экземпляра.

Демон SSH использует AuthorizedKeysCommand и AuthorizedKeysCommandUser, которые настраиваются при установке Instance Connect, для поиска открытого ключа в метаданных экземпляра для аутентификации и подключения вас к экземпляру.

(*) Amazon Linux 2 2.0.20190618 или более поздней версии и Ubuntu 20.04 или более поздней версии поставляются с предварительно настроенным подключением экземпляров EC2. Для других поддерживаемых дистрибутивов Linux необходимо настроить Instance Connect для каждого экземпляра, который будет поддерживать использование Instance Connect. Это одноразовое требование для каждого экземпляра.

Ссылки:

Настройка подключения экземпляра EC2
Подключение с помощью подключения экземпляра EC2
Защита хостов-бастионов с помощью Amazon EC2 Instance Connect

ВАЖНО: вы должны запустить 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.

Как упоминалось на странице блога Atlassian, создайте файл config в папке .ssh, включая следующий текст:

#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

Затем вы можете просто оформить заказ с доменным суффиксом, а в проектах вы можете настроить имена авторов и т. д. локально.

На Ubuntu 18.04 (Bionic Beaver) делать нечего .

После успешного создания второго ключа SSH система попытается найти соответствующий ключ SSH для каждого соединения.

Чтобы было ясно, вы можете создать новый ключ с помощью этих команд:

# 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

Мне нравится подход к установке следующего в файле ~/.ssh/config:

# Configuration 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 repository works and sometimes the
# other depending on which key is used first.
#  AddKeysToAgent yes

# I only use my private id file so all private
# repositories don't need the environment variable
# `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
  IdentityFile ~/.ssh/id_rsa

Затем в вашем репозитории вы можете создать файл .env, который содержит команду ssh, которую нужно использовать:

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

Если вы затем используете, например. dotenv переменная окружения экспортируется автоматически, и вы можете укажите ключ, который вы хотите для каждого проекта/каталога. Кодовая фраза запрашивается только один раз, поскольку она добавляется в цепочку для ключей.

Это решение отлично работает с Git и предназначено для работы на Mac (из-за UseKeychain).

В CentOS 6.5 с OpenSSH_5.3p1 и OpenSSL 1.0.1e-fips я решил проблему следующим образом: переименовать мои ключевые файлы, чтобы ни один из них не имел имени по умолчанию.

Мой каталог .ssh содержит id_rsa_foo и id_rsa_bar, но не содержит id_rsa и т. д.

Вы можете попробовать этот пакет sshmulti npm для поддержки нескольких ключей SSH.