bonnopc / multipleSSHkeysForUnix.md
Follow these steps below to enable multiple SSH keys on your device with UNIX Based OS (MacOS/ Ubuntu/ Debian etc.). Suppose, you have two different users/ accounts, one is personalAccount and another is companyAccount . And you have already a default key configured with personalAccount . (If you haven’t set up your default ssh-key yet, please follow this article before going ahead with these steps described below.)
1. Generate another ssh-key
Generate a new ssh-key for your companyAccount .
cd ~/.ssh ssh-keygen -t rsa -C "your_email@youremail.com"
2. Clear previous cached keys
Then add your keys as following —
ssh-add ~/.ssh/id_rsa ssh-add ~/.ssh/id_rsa_company
You can always check your keys by entering following command
5. Create or Update config
You may have no config file right now. to create a config enter
Or maybe, you already have a config file in your ~/.ssh directory. Now you have to edit & save this file and include these lines as described below. (You can use nano config or open and edit with your favorite editor.)
Host personalAccount.github.com HostName github.com IdentitiesOnly yes IdentityFile ~/.ssh/id_rsa Host companyAccount.github.com HostName github.com IdentitiesOnly yes IdentityFile ~/.ssh/id_rsa_company
As you can see here, you’ll be using two hosts as personalAccount.github.com & companyAccount.github.com .
6. Cloning a (Private) Repository
You can always use git clone git@github.com:someUserName/example-repo.git by using your default or personalAccount credentials. But you have to change the url while cloning from the companyAccount repositories.
Suppose we have a repo url of something like git@github.com:companyAccount/some-private-repo.git , then you have to change this url and clone this repo as following —
git clone git@companyAccount.github.com:companyAccount/some-private-repo.git Note: the host name ( companyAccount.github.com ) should match with the Host described as in the config file.
Как эффективно работать с несколькими SSH-ключами
Перевод статьи «How to Manage Multiple SSH Keys».
Можно смело утверждать, что большинство разработчиков рано или поздно знакомятся с SSH. Это один из самых используемых протоколов для безопасного обмена данными. Вы можете использовать SSH для подключения к удаленным серверам, в том числе для управления кодом при помощи Git и синхронизации с удаленными репозиториями.
Несмотря на то, что хорошей практикой считается иметь одну пару ключей (закрытый и открытый) для каждого устройства, иногда возникает потребность использовать несколько ключей. Также эти ключи могут иметь необычные имена.
Например, вы можете использовать одну пару SSH-ключей для работы над внутренними проектами вашей компании, но при этом пользоваться другими ключами для доступа к серверам корпоративных клиентов. Вы можете даже завести отдельную пару ключей для доступа к вашему собственному (частному) серверу.
С того момента как у вас возникает потребность добавить второй ключ, управление ключами может стать обременительным делом. Надеюсь, эта статья поможет всем, у кого возникают проблемы с SSH-ключами.
Я буду исходить из того, что мои читатели уже имеют базовые знания Git и SSH. В большинстве примеров в этой статье мы будем использовать Git, но, разумеется, все сказанное будет касаться и любых других SSH-коммуникаций. Впрочем, кое-какие приемы работы, специфические для Git, я тоже упомяну.
Пристегните ремни и полетели!
Работа с одним SSH-ключом
Для начала, давайте рассмотрим, как может выглядеть работа с SSH до того, как у вас появляется несколько ключей.
У вас есть один закрытый ключ, хранящийся в файле ~/.ssh/id_rsa, и соответствующий открытый ключ в файле ~/.ssh/id_rsa.pub.
Давайте представим, что вы хотите отправлять изменения в коде на удаленный Git-сервер, допустим, на GitHub (почему бы и нет). Для этого вам нужно сначала добавить на GitHub ваш открытый ключ. Я не буду останавливаться на этом шаге, найти информацию по этой теме довольно легко.
Предположим, что вас зовут Стив (англ. Steve) и вы работаете над очень секретным проектом с использованием Raspberry Pies для прослушивания сетевого трафика.
Чтобы начать работу, вам нужно клонировать git-репозиторий, используя SSH:
git clone git@github.com:steve/raspberry-spy.git
На этом этапе GitHub «думает»: «О, приватный репозиторий! Нам нужно зашифровать трафик при помощи имеющегося у меня открытого ключа и вашего закрытого ключа».
Открытый ключ вы добавили в свой профайл на GitHub, но SSH должен как-то понять, где находится соответствующий закрытый ключ.
Не имея ни малейшего представления, какой закрытый ключ должен использоваться при SSH-соединении с git@github.com, SSH-клиент пытается найти ключ в стандартном месте — ~/.ssh/id_rsa (это лучшее, что он может предположить). Если по этому адресу не будет соответствующего файла, вы получите ошибку:
Cloning into 'raspberry-spy'… Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Если у вас все же хранится какой-то ключ в ~/.ssh/id_rsa, SSH-клиент использует этот закрытый ключ для шифрования соединения. Если ключ защищен паролем (как это и должно быть), вам будет предложено ввести этот пароль:
Enter passphrase for key '/Users/steve/.ssh/id_rsa':
Если вы введете правильный пароль и если выбранный SSH-клиентом ключ составляет пару с открытым ключом в вашем профайле, все пройдет хорошо и репозиторий будет успешно клонирован.
Но что, если вы дали своему файлу с закрытым ключом нестандартное имя (например, ~/.ssh/_id_rsa)? SSH-клиент не сможет определить, где хранится закрытый ключ. Вы получите ту же самую ошибку Permission denied …, что и раньше.
Если вы хотите использовать закрытый ключ с нестандартным именем, его нужно добавить вручную:
После ввода пароля вы при помощи команды ssh-add -l сможете проверить, добавился ли ключ в ssh-agent (SSH -клиент). Эта команда выведет все ключи, доступные на данный момент SSH-клиенту.
Если вы теперь попробуете клонировать репозиторий, вы сможете это сделать.
Пока все хорошо, не так ли?
Внимательный читатель мог заметить несколько потенциальных проблем.
Для начала, если вы перезагрузите свой компьютер, ssh-agent тоже перезагрузится, и вам придется заново добавлять ваши ключи с нестандартными именами и вводить пароли.
Можно ли автоматизировать добавление ключей или как-то указать, какие ключи для каких серверов использовать?
Можно ли каким-то образом сохранить пароли, чтобы не вводить их каждый раз? Если бы только существовало что-то вроде keychain («связка ключей») для хранения SSH-ключей, защищенных паролями!
Можете быть спокойны: на все эти вопросы есть ответы.
Знакомьтесь: SSH config
Оказывается, нам может помочь файл конфигурации SSH. Это конфигурационный файл для SSH-соединений, создаваемый для каждого отдельного пользователя.
Создайте новый файл ~/.ssh/config и откройте его для редактирования.
Управление SSH-ключами с нестандартными именами
Первое, что мы хотим сделать при помощи файла config, это избавиться от необходимости постоянно добавлять SSH-ключи с нестандартными именами при помощи ssh-add.
Предположим, ваш ключ имеет имя ~/.ssh/_id_rsa. В файл config нужно добавить следующие строки:
Host github.com HostName github.com User git IdentityFile ~/.ssh/_id_rsa IdentitiesOnly yes
Выполните команду ssh-add -D, чтобы убедиться, что вашего файла ~/.ssh/_id_rsa нет в ssh-agent. Эта команда удалит все ключи из текущей сессии ssh-agent. Сессия сбрасывается при каждом вашем выходе из системы или перезагрузке компьютера (или когда вы вручную убиваете процесс ssh-agent). При помощи команды ssh-add -D мы можем смоделировать перезагрузку.
Если вы попробуете клонировать ваш GitHub-репозиторий сейчас, все будет происходить так же, как если бы мы добавили ключ вручную (как мы делали раньше). Вам будет предложено ввести пароль:
git clone git@github.com:steve/raspberry-spy.git Cloning into 'raspberry-spy'… Enter passphrase for key '/Users/steve/.ssh/_id_rsa':
Обратите внимание, что ключ, пароль от которого у нас спрашивают, это именно тот ключ, который мы указали в файле config. После ввода корректного пароля репозиторий будет успешно клонирован.
Примечание: если после успешного клонирования вы попытаетесь выполнить git pull, вам опять предложат ввести пароль. С этим мы разберемся дальше.
Важно, чтобы значение Host (github.com) в файле config и адрес в URI git@github.com:steve/raspberry-spy.git совпадали. Вы также можете изменить значение Host в конфигурационном файле на mygithub и клонировать репозиторий, используя URI git@mygithub:steve/raspberry-spy.git.
Должно быть, ваш мозг уже радуется, понимая, что все его проблемы с SSH-ключами решены. Вот несколько полезных примеров конфигурации:
Host bitbucket-corporate HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_corp IdentitiesOnly yes
Теперь вы можете использовать git clone git@bitbucket-corporate:company/project.git
Host bitbucket-personal HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes
Теперь вы можете использовать git clone git@bitbucket-personal:steve/other-pi-project.git
Host myserver HostName ssh.steve.com Port 1111 IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes User steve IdentitiesOnly yes
А сейчас вы можете подключаться по SSH к собственному серверу, используя ssh myserver. Круто? Больше не нужно каждый раз, запуская ssh, вручную вводить номер порта и имя пользователя.
Бонус: настройки для каждого отдельного репозитория
Вы также можете указать, какой именно ключ нужно использовать для каждого репозитория, переопределив значения в конфигурации SSH.
Можно прописать специальную SSH-команду, задав ее в качестве значения sshCommand под core в /.git/config. Например:
[core] sshCommand = ssh -i ~/.ssh/id_rsa_corp
Это возможно для git 2.10 или более новых версий. Чтобы избежать редактирования файла вручную, можно воспользоваться следующей командой:
git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'
Управление паролями
Последняя часть головоломки — управление паролями. Нам хотелось бы избежать введения пароля при каждой инициации SSH-соединения. Для этого мы можем использовать специальное программное обеспечение для управления связками ключей. Оно поставляется в MacOS и различных дистрибутивах Linux.
Начните с добавления вашего ключа в связку (keychain). Для этого к команде ssh-add нужно добавить опцию -K:
ssh-add -K ~/.ssh/id_rsa_whatever
Теперь вы можете видеть ваш SSH-ключ в связке. На MacOS это выглядит примерно так:
Если вы удалите ключи из ssh-agent при помощи команды ssh-add -D (как я уже говорил, это также происходит при перезагрузке компьютера) и попытаетесь установить SSH-соединение, вам будет предложено ввести пароль. Почему? Мы только что добавили ключ в связку. Если вы снова проверите Keychain Access, вы заметите, что добавленный при помощи команды ssh-add -K ключ по-прежнему находится в связке. Странно, правда?
Оказывается, нужно сделать еще один шаг. Откройте ваш конфигурационный файл SSH и добавьте в него следующие строки:
Host * AddKeysToAgent yes UseKeychain yes
Теперь SSH будет искать ключ в связке, и если найдет, то вам не нужно будет вводить пароль. Ключ также будет добавлен в ssh-agent.
Для MacOS это будет работать в версии MacOS Sierra 10.12.2 и в более поздних версиях. Для Linux можно использовать что-то вроде gnome-keyring и это может сработать даже без последней модификации SSH-конфига. Что касается Windows — кто знает.
Надеюсь, эта статья будет вам полезной. А теперь — вперед, приступайте к работе над SSH-конфигом!