Несколько SSH-ключей для Git

Логотип Git

Быстрые ссылки

Как SSH работает с Git?
Создание нового SSH-ключа
Правка ~/.ssh/config
Временное переопределение SSH

Использование SSH-ключей безопаснее паролей — это справедливо и для Git. В отличие от пароля, SSH-ключ труднее изменить и сложнее управлять множеством ключей. Правка конфигурации SSH позволяет подключаться к разным Git-репозиториям с разными ключами без поспешной замены ключа по умолчанию.

Как SSH работает с Git

Когда вы используете SSH-URL (git@github.com:…), Git не «придумывает» свой способ аутентификации — он вызывает системную утилиту ssh и устанавливает обычное SSH-соединение к серверу. Поскольку вызывается стандартная команда ssh, поведение по умолчанию такое же, как если бы вы вручную выполнили ssh: будет использован приватный ключ по умолчанию, обычно расположенный в

~/.ssh/id_rsa

Если у вас несколько ключей или вы хотите отдельный ключ для рабочего и личного аккаунта, править нужно конфигурацию SSH, а не Git.

Создание нового SSH-ключа

Если у вас ещё нет отдельного ключа, создайте его так:

ssh-keygen -t rsa -f ~/.ssh/github_personal

Ключи появятся как приватный файл (~/.ssh/github_personal) и публичный (~/.ssh/github_personal.pub). Защитите приватный ключ паролем (passphrase) при необходимости.

Советы:

Для новых ключей используйте тип rsa или ed25519 (ed25519 короче и современнее: ssh-keygen -t ed25519 -f ~/.ssh/github_personal).
Никогда не выкладывайте приватный файл в репозиторий.

Правка ~/.ssh/config

Файл конфигурации SSH позволяет задавать блоки Host, которые соответствуют имени хоста в командной строке и могут менять путь к IdentityFile (файлу ключа), имя пользователя или другие опции.

Пример простого блока для одного альтернативного ключа:

Host github
    Hostname github.com
    IdentityFile ~/.ssh/id_rsa.github
    IdentitiesOnly yes

Чтобы использовать два разных ключа для одного хоста (например, github.com) — создайте два блока с разными именами Host, но одинаковым Hostname:

Host personal
    Hostname github.com
    IdentityFile ~/.ssh/github_personal
    IdentitiesOnly yes

Host work
    Hostname github.com
    IdentityFile ~/.ssh/github_work
    IdentitiesOnly yes

Важно: «Host» здесь — псевдоним, который вы впоследствии используете в SSH-URL.

После того как вы добавили нужные блоки, замените обычный удалённый адрес в Git на адрес, использующий псевдоним Host:

git remote remove origin
git remote add origin git@personal:username/repository.git

Git передаст хост personal утилите ssh, и ssh применит соответствующий IdentityFile. Таким образом в одном компьютере можно управлять несколькими аккаунтами без переключения ключей по умолчанию.

Временное переопределение

Если не хочется править конфиг или нужно временно использовать другой ключ, задайте GIT_SSH_COMMAND в текущей сессии:

GIT_SSH_COMMAND='ssh -i ~/.ssh/github_personal -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' git pull

После выполнения этой команды Git будет использовать указанный SSH-командный вариант для текущего процесса. Можно также задать другую бинарную утилиту через переменную GIT_SSH.

Важно: отключать проверку known_hosts небезопасно — используйте опции -o UserKnownHostsFile и -o StrictHostKeyChecking только для локальной отладки.

Когда такой подход не подходит

Если вы используете HTTPS для всех удалённых репозиториев (тогда SSH-конфиг не применяется).
Если ваша среда ограничивает доступ к ~/.ssh (например, некоторые CI-системы) — лучше использовать секреты/ключи, установленные через систему CI.
Если вы обязаны централизованно управлять ключами (корпоративная политика) — согласуйте изменения с администратором.

Альтернативные подходы

Использовать HTTPS + credential manager (менеджер учётных данных). Удобно для персональных проектов.
Использовать ssh-agent и добавлять в него нужный ключ перед работой: ssh-add ~/.ssh/github_personal.
Хранить ключи в менеджере секретов CI/CD и доставлять их в рантайме.

Мини‑методика: быстрый SOP для настройки (шаги)

Создайте ключ: ssh-keygen -t ed25519 -f ~/.ssh/github_personal
Добавьте публичный ключ в профиль GitHub/GitLab.
Откройте или создайте ~/.ssh/config и добавьте блок «Host personal» (см. пример выше).
В локальном репозитории смените удалённый URL: git remote set-url origin git@personal:username/repo.git
Проверка: ssh -T git@personal

Чеклист ролей

Разработчик:

Создал ключ и добавил публичный ключ в аккаунт.
Настроил ~/.ssh/config с правильным IdentityFile.
Проверил ssh -T git@.

Сисадмин:

Обеспечил политику хранения и удаления ключей.
Настроил ограничения доступа к ~/.ssh (chmod 700/.ssh, chmod 600/*.key).

Критерии приёмки

git push/pull работают без запроса пароля для указанного аккаунта.
ssh -T git@ возвращает успешную аутентификацию для нужного пользователя.
Приватные ключи не хранятся в репозиториях и имеют корректные права.

Практические советы и жесткие ограничения безопасности

Установите права: chmod 700 ~/.ssh и chmod 600 ~/.ssh/* (особенно приватные ключи).
Используйте passphrase для приватных ключей.
По возможности используйте ed25519 вместо rsa.
Не отключайте проверку known_hosts в продуктиве.

Быстрый факт-бокс

Формат ключа: приватный файл + публичный файл (.pub).
Файл конфига: ~/.ssh/config.
Альтернатива: HTTPS + credential helper.

Decision flowchart

flowchart TD
    A[Нужно несколько ключей?] -->|Да| B{Используется SSH или HTTPS?}
    B -->|SSH| C[Настроить ~/.ssh/config с Host-алиасами]
    B -->|HTTPS| D[Использовать credential helper]
    C --> E[Обновить git remote на git@alias:...]
    E --> F[Проверить: ssh -T git@alias и git pull]
    A -->|Нет| G[Оставить стандартный ключ или использовать ssh-agent]

Короткий глоссарий

IdentityFile — путь к приватному ключу, используемому SSH.
Host — псевдоним в ~/.ssh/config, который вы используете в URL для передачи SSH.
ssh-agent — демон для хранения расшифрованных ключей в памяти.

Резюме

Использование псевдонимов Host в ~/.ssh/config — простой и надёжный способ управлять несколькими SSH-ключами для Git. Это даёт гибкость: можно держать рабочие и личные ключи отдельно, не меняя глобальные настройки SSH. Для временных случаев подходит GIT_SSH_COMMAND или ssh-agent.

Важно: соблюдайте базовые правила безопасности (права на файлы, passphrase, не отключать host-key проверку в продуктиве).