Если вы начали работать с Git и GitHub из командной строки, то наверняка столкнулись с необходимостью постоянно вводить логин и пароль. Это не только неудоб��о, но и небезопасно. Правильное решение — использовать SSH-ключи. Это как цифровой пропуск, который позволяет вашему компьютеру и боевому серверу “представляться” GitHub без паролей.
В этой статье мы пошагово разберем весь процесс настройки и рассмотрим все "подводные камни", с которыми вы можете столкнуться.
Почему Git постоянно спрашивает пароль?
По умолчанию, когда вы клонируете репозиторий с помощью URL-адреса вида `https://...`, Git использует протокол HTTPS. Каждая операция (`push`, `pull`) — это, по сути, новый запрос к серверу, который требует аутентификации. SSH решает эту проблему раз и навсегда.
Шаг 1: Проверяем, есть ли у вас уже SSH-ключи
Прежде чем создавать новые ключи, стоит проверить, может они уже есть. Откройте терминал и введите:
ls -al ~/.ssh
Ищите файлы с именами вроде `id_rsa.pub`, `id_ecdsa.pub` или (самый современный вариант) `id_ed25519.pub`.
Проблемная точка №1: Папки .ssh нет или она пуста
Мы столкнулись с тем, что команда показала только файл `known_hosts`. Это означает, что ключей на машине нет и их нужно создать с нуля. **Это нормально для новой системы.**
Шаг 2: Создаем новый SSH-ключ
Если ключей не нашлось, создадим их. Используйте команду ниже, подставив свой email от GitHub:
ssh-keygen -t ed25519 -C "vash_email@example.com"
Система задаст пару вопросов:
- **Куда сохранить ключ?** — Просто нажмите Enter, чтобы согласиться с путем по умолчанию. Это критически важно!
- **Придумать пароль (passphrase)?** — Можете просто нажать Enter дважды. Это пароль для самого ключа, а не для GitHub. Для простоты можно оставить пустым.
После этого в папке `~/.ssh` появятся два файла: `id_ed25519` (приватный, секретный ключ) и `id_ed25519.pub` (публичный, им можно делит��ся).
Шаг 3: Добавляем публичный ключ в GitHub
Теперь нужно "познакомить" GitHub с вашим новым ключом.
- **Скопируйте публичный ключ.** Выведите его содержимое в терминал и скопируйте всю строку:
cat ~/.ssh/id_ed25519.pub
>
Выглядеть это будет так:
ssh-ed25519 AAAAC3... vash_email@example.com. Копировать нужно всё.
- **Зайдите на GitHub:**
<li>Нажмите на иконку профиля → **Settings**.
- В меню слева выберите **SSH and GPG keys**.
- Нажмите зеленую кнопку **New SSH key**.
- **Вставьте ключ:**
<li>**Title:** Дайте ключу понятное имя (например, "Мой рабочий компьютер").
- **Key:** Вставьте скопированную строку.
- Нажмите **Add SSH key**.
Шаг 4: Переключаем репозиторий с HTTPS на SSH
Ваш локальный репозиторий все еще "помнит" старый HTTPS-адрес. Нужно это исправить.
git remote set-url origin git@github.com:VASH_LOGIN/VASH_REPO.git
Замените `VASH_LOGIN` и `VASH_REPO` на ваши данные. Например: `git@github.com:eudigitaldotru/mastinonew.git`.
Шаг 5: Финальная проверка и решение проблем
Попробуйте выполнить команду `git push`. В этот момент могут возникнуть последние ошибки.
Проблемная точка №2: Ошибка Permission denied (publickey)
Мы столкнулись с этой ошибкой. Она означает, что GitHub не узнал ключ, который ему предъявил ваш компьютер. Причина почти всегда в том, что SSH-агент (программа, управляющая ключами) не "подхватил" ваш новый ключ.
Решение: Явно добавить ключ в SSH-агент
Выполните две команды:
- Запуск��ем агент:
eval "$(ssh-agent -s)"
- Добавляем в него наш ключ:
ssh-add ~/.ssh/id_ed25519
После этого можно проверить соединение напрямую:
ssh -T git@github.com
Если вы видите в ответ приветствие `Hi VASH_LOGIN! You've successfully authenticated...` — поздравляем, все настроено правильно! Команда `git push` теперь будет работать без пароля.
Бонусный трек: Настройка для боевого сервера
Ваш рабочий компьютер и боевой сервер — это две разные машины. Чтобы выполнять `git pull` на сервере без пароля, вам нужно повторить **весь этот процесс (Шаги 1-5) заново, но уже подключившись к вашему серверу по SSH**. Создайте на нем отдельный ключ и добавьте его в GitHub с понятным названием, например, "Боевой сервер".
Один SSH-ключ на все сайты? Как работает доступ на сервере
Когда вы настраиваете SSH-ключ для доступа к GitHub с вашего сервера, возникает логичный и важный вопрос: этот ключ предназначен для одного конкретного сайта или для всего сервера?
Краткий ответ: Ключ привязан к ПОЛЬЗОВАТЕЛЮ на сервере, а не к папке сайта.
Это значит, что один и тот же ключ будет работать для всех сайтов и репозиториев, с которыми вы работаете ��т имени этого пользователя. Давайте разберем это на простой аналогии.
Аналогия с паспортом
Представьте, что:
- **Ваш сервер (`nash`)** — это целая страна.
- **Пользователь (`bitrix`)** — это гражданин этой страны.
- **SSH-ключ (`/home/bitrix/.ssh/id_ed25519`)** — это его личный паспорт. Паспорт хранится в его "доме" (домашней директории `/home/bitrix/`).
- **GitHub** — это дружественное государство, в посольство которого вы заранее отнесли копию паспорта (ваш публичный ключ), чтобы гражданина узнавали.
- **Папка сайта (`/ext_www/1.eu-digital.ru`)** — это просто один из офисов, куда гражданин `bitrix` ходит на работу.
Гражданин `bitrix` может работать в разных офисах (в разных папках сайтов), но паспорт у него всегда один и тот же. Когда ему нужно подтвердить свою личность для связи с другим государством (GitHub), он показывает свой паспорт. Неважно, из какого офиса он это делает.
Что это значит на практике?
- **Один пользователь — один ключ.** Ключ, который мы создали, принадлежит пользователю `bitrix`. Он может использовать его из любой директории, к которой у него есть доступ.
- **Новый сайт — старый ключ.** Если вы создадите на этом же сервере сайт `2.eu-digital.ru`, и его файлы тоже будут принадлежать пользователю `bitrix`, вам **не нужно** создавать новый ключ. Вы просто зайдете в новую папку и выполните `git pull`. Система автоматически использует существующий "паспорт" пользователя `bitrix`.
- **Другой пользователь — другой ключ.** Если на сервере появится другой системный пользователь (например, `admin` или `www-data`), и ему понадобится доступ к GitHub, для него нужно будет создавать **свой собственный, отдельный SSH-ключ**.
Вывод
Вы настроили аутентификацию для пользователя `bitrix` на всем сервере `nash`. Теперь этот пользователь может работать с любыми вашими репозиториями на GitHub из любой папки, используя один и тот же ключ.
Надеюсь, эта инструкция поможет вам и вашим читателям сэкономить время и нервы!
Бонус. Нормальный гитигнор для Аспры и Битрикс
# Исключаем системные файлы macOS и редакторы кода
.DS_Store
.idea/
.vscode/
*.swp
*.swo
# Исключаем ядро D7, сгенерированные файлы и кеш Битрикса
/bitrix/backup/
/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/bitrix/tmp/
/bitrix/updates/
# Исключаем загружаемый пользователями контент
# Обычно его не хранят в Git, но если вам нужно, закомментируйте строку ниже
/upload/
/upload.tar.gz
# ВАЖНО: Исключаем файлы с чувствительными данными (пароли, ключи)
# Рекомендуется создать их копии с расширением .example и добавить в Git
# Например: cp bitrix/php_interface/dbconn.php bitrix/php_interface/dbconn.php.example
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/.settings_extra.php
# Логи и статистика
/bitrix/modules/*.log
/bitrix/modules/main/admin/upd_log.txt
/bitrix/modules/search/data/
# Прочие сгенерированные файлы
/urlrewrite.php
/web.config
# Зависимости Composer
/vendor/
/composer.lock
/bitrix/modules/**/*.zip
/bitrix/wizards/**/*.zip