SSH vs HTTPS в Git: как перестать вводить пароли и не потерять ключи

Вы устали вводить пароли или токены при каждом git pull и git push?
Копируете SSH‑ключ на каждый сервер и боитесь, что его украдут или он «застрянет» в логах?
В этой статье разберём, когда выбирать SSH, когда HTTPS, как безопасно настроить доступ к GitHub / GitLab и как не превращать CI/CD в сборник токенов‑паролей.

Выбор между SSH и HTTPS — это не вопрос вкуса, а вопрос безопасности и удобства автоматизации. Разберёмся, как настроить доступ так, чтобы он не мешал работать.

1. SSH: Ключи и безопасность

SSH (Secure Shell) — стандарт для постоянной работы. Вместо паролей здесь используются пары ключей. Вы подтверждаете свою личность владением приватным ключом, который никогда не покидает ваш компьютер.

Как не разбрасываться ключами (SSH Agent)

Главная ошибка — копировать свой приватный ключ на каждый сервер, где нужно сделать git pull. Это дыра в безопасности. Вместо этого используйте Agent Forwarding.

Суть: Ваш локальный компьютер выступает в роли «хранителя» ключа. Когда удаленный сервер хочет постучаться в GitHub, он пробрасывает запрос к вашему локальному агенту.

1. Добавьте ключ в агент локально

ssh-add ~/.ssh/id_ed25519

2. Разрешите проброс в ~/.ssh/config

Вместо того чтобы каждый раз писать ssh -A, настройте автоматизацию для нужных хостов:

Host my-server
    HostName 1.2.3.4
    User admin
    ForwardAgent yes

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

2. Несколько аккаунтов на одном устройстве

Частая ситуация: рабочий GitLab и личный GitHub. Использовать один ключ для всего — плохая практика. Чтобы Git сам понимал, какой ключ подложить, используйте алиасы в ~/.ssh/config.

2.1. Алиасы в ~/.ssh/config

Пример конфигурации:

# Рабочий GitLab
Host gitlab.work
    HostName gitlab.company.com
    IdentityFile ~/.ssh/id_ed25519_work

# Личный GitHub
Host github.com
    HostName github.com
    IdentityFile ~/.ssh/id_ed25519_personal

Как это использовать:

• При клонировании рабочего проекта используйте имя хоста из конфига:

  git clone git@gitlab.work:department/project.git
  

• При работе с личным GitHub в git remote‑адресах останется стандартное git@github.com:user/repo.git.

3. Когда HTTPS объективно лучше

HTTPS не стоит списывать со счетов. С тех пор как GitHub перешёл на Personal Access Tokens (PAT), этот протокол стал незаменим в ряде случаев.

3.1. Строгие корпоративные сети

Если системные администраторы закрыли порт 22 (SSH), HTTPS на стандартном 443 порту — ваше спасение.

3.2. Docker и CI/CD

Внутри Docker‑контейнеров или временных пайплайнов проще прокинуть токен через переменную окружения, чем возиться с генерацией и регистрацией SSH‑ключей.

3.3. Разовые задачи

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

3.4. Опасности https://<TOKEN>@... и безопасные альтернативы

Использование токена прямо в URL:

git clone https://<TOKEN>@github.com/username/repo.git

— крайне небезопасная практика: токен может попасть в:

• историю shell (~/.bash_history);
• логи CI/CD;
• скриншоты и заметки.

Лучше так:

• используйте git config с credential.helper:

  git config credential.helper store
  # затем при первом запросе ввести логин/токен
  

• либо передавайте токен через переменные окружения в CI/CD (GitHub Actions, GitLab CI и т.п.).

4. Сравнение SSH и HTTPS

Вывод таблицы:

• Для своей машины и серверов — SSH с агентом и ~/.ssh/config.
• Для CI/CD, Docker‑сборок, ограниченных сетей и разовых задач — HTTPS с токенами, но без токенов в URL.

5. Как переключить протокол в существующем проекте

Если вы склонировали проект по HTTPS, а хотите перейти на SSH (или наоборот), не нужно удалять папку и качать заново. Просто смените URL удаленного репозитория.

Переключение на SSH

git remote set-url origin git@github.com:user/repo.git

Переключение на HTTPS

git remote set-url origin https://github.com/user/repo.git

После этого все последующие git pull / git push будут использовать новый протокол.

Заключение

Для своей машины и доверенных серверов выбирайте SSH с настроенным агентом и ~/.ssh/config — это безопасно, удобно и масштабируется.
HTTPS оставьте для:

• CI/CD пайплайнов;
• Docker‑сборок;
• ограниченных сетевых условий;
• одноразовых задач.

Грамотная комбинация этих подходов — это и есть зрелая DevOps‑практика.

Практический чек‑лист: как настроить

1. Сгенерировать SSH‑ключи:

   ssh-keygen -t ed25519 -C "your_email@example.com"
   

2. Добавить ключ в SSH‑агент:

   ssh-add ~/.ssh/id_ed25519
   

3. Настроить ~/.ssh/config для нескольких аккаунтов:

   Host gitlab.work
       HostName gitlab.company.com
       IdentityFile ~/.ssh/id_ed25519_work
   
   Host github.com
       HostName github.com
       IdentityFile ~/.ssh/id_ed25519_personal
   

4. Проверить доступ:

   ssh -T git@gitlab.work
   ssh -T git@github.com
   

5. В CI/CD использовать HTTPS с токенами через переменные окружения, не вставляя их в URL.