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

Я хочу использовать несколько закрытых ключей для подключения к разным серверам или различным частям одного и того же сервера (я использую системное администрирование сервера, администрирование Git и обычное использование Git на одном и том же сервере). Я попытался просто сложить ключи в id_rsa файлы безрезультатно.

Видимо, простой способ сделать это - использовать команду

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

Это довольно громоздко.

Любые предложения о том, как сделать это немного проще?

Источник

21 ответ

Решение

От моего .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 попробовать несколько ключей подряд при подключении. Вот как:

$ 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 даже если бы он был один.

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

Источник

Предыдущие ответы правильно объяснили способ создания файла конфигурации для управления несколькими ключами 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 заменяется псевдонимом "company", как мы определили в файле конфигурации.

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

Источник

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

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

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

ssh friendly-name

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

Источник 
foo:~$ssh-add ~/.ssh/xxx_id_rsa

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

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

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

chmod 0600 ~/.ssh/xxx_id_rsa
Источник

  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.pub, accountB.pub) должны существовать в ~/.ssh/ каталог.

    $ 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 git@bitbucket.org: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 например ssh-add ~/.ssh/id_rsa
  3. Подтвердить $ ssh-add -l
  4. Проверьте это с $ssh -v <host url> например ssh -v git@assembla.com
Источник

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

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

your_ssh_keyбез какого-либо расширения. Не использовать.pub.

Источник

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

Я столкнулся с этой проблемой некоторое время назад, когда у меня было две учетные записи 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

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

git clone git @personal.bitbucket.org: имя /personalproject.git

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

Источник

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

Источник

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

Создайте ключ SSH

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

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

nano ~/.ssh/config

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

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

ssh-add -D

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

ssh -T git@company.gitlab.com

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

ssh -T git@gitlab.com

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

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

Счет компании

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

Личный / стандартный аккаунт

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

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

Источник

Тем,aws, кто работает с я настоятельно рекомендую работать с EC2 Instance Connect.

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

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

После установки соответствующих пакетов ( pip install ec2instanceconnectcliили клонирование репозитория напрямую), вы можете легко подключиться к нескольким экземплярам 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 Instance Connect. Для других поддерживаемых дистрибутивов Linux необходимо настроить Instance Connect для каждого экземпляра, который будет поддерживать использование Instance Connect. Это единовременное требование для каждого экземпляра.

Ссылки:

Настройка EC2 Instance Connect
Connect с помощью EC2 Instance Connect
Защита ваших хостов-бастионов с помощью Amazon EC2 Instance Connect

Источник

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

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

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

 ssh aws
Источник

На Ubuntu18.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
Источник

Как упомянуто на странице блога atlassian, создайтеконфигурацию в .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

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

Источник

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

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

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

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

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

Хозяин пиццы

HostName github.com

PreferredAuthentication publickey # необязательно

IdentityFile ~/.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 = git@github.com:yourgitusername/pizzahut_repo.git

(New) URL = git@pizza:yourgitusername/pizzahut_repo.git
Источник

Мне нравится подход к установке следующего в файле ~/.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, переменная среды экспортируется автоматически и whoop whoop, вы можете указать ключ, который хотите для каждого проекта / каталога. Фраза-пароль запрашивается только один раз, поскольку она добавляется в связку ключей.

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

Источник

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

Источник

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

Источник

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

Источник
Другие вопросы по тегам