Настройка SSH-ключа решает 90% таких случаев. Вы научитесь генерировать ключи, добавлять их правильно и проверять соединение. Это сэкономит часы на отладку и позволит клонировать репозитории без паролей.

Что значит ошибка Permission denied (publickey)

Ошибка Permission denied (publickey) возникает, когда SSH-сервер отклоняет подключение из-за проблем с ключами. Обычно это GitHub или ваш сервер, который ожидает публичный ключ, но не находит его или не может его прочитать. Например, при команде git clone git@github.com:username/repo.git терминал выдает предупреждение о хосте и потом fatal-ошибку.

Сервер проверяет ваш приватный ключ локально и сравнивает с публичным на своей стороне. Если ключ не загружен в ssh-agent, права доступа неверные или ключ не добавлен в аккаунт — доступ блокируется. Реальные примеры: на Ubuntu после git clone падает с IP GitHub в known_hosts, но без аутентификации. На Windows в Git Bash то же самое, если ssh-agent не запущен.

Вот типичные причины в таблице:

• Проверьте наличие ключей: Запустите ssh-add -l -E sha256 — увидите список или ошибку.
• Запустите ssh-agent: eval "$(ssh-agent -s)" — это фоновая служба для ключей.
• Нюанс: На macOS или Linux используйте ssh-add ~/.ssh/id_rsa после запуска.

Генерация и добавление SSH-ключа в GitHub

Сначала убедитесь, что у вас есть пара ключей: приватный (секретный) и публичный (.pub). Если нет, сгенерируйте их командой ssh-keygen -t ed25519 -C "your_email@example.com". Нажмите Enter три раза для дефолтных настроек — файлы появятся в ~/.ssh/.

Публичный ключ нужно добавить в GitHub, иначе сервер его не узнает. Скопируйте содержимое cat ~/.ssh/id_ed25519.pub (или id_rsa.pub) и перейдите в настройки аккаунта: Settings > SSH and GPG keys > New SSH key. Вставьте ключ, дайте название и сохраните. Это базовый шаг, который решает проблему в большинстве случаев.

После добавления протестируйте:

1. Запустите ssh-agent: eval "$(ssh-agent -s)".
2. Добавьте ключ: ssh-add ~/.ssh/id_ed25519.
3. Проверьте связь: ssh -T git@github.com — должно ответить “Hi username! You’ve successfully authenticated”.

Важно: Если используете RSA, берите 4096 бит: ssh-keygen -t rsa -b 4096. Для старых систем ed25519 лучше, но проверьте совместимость.

Таблица сравнения типов ключей:

• Скопируйте ключ правильно: Весь вывод cat ~/.ssh/*.pub без лишнего.
• Проверьте email: В комментарии ключа должен быть ваш GitHub-email.
• Нюанс для Windows: В Git Bash пути ~/.ssh/, но проверьте C:\Users\username.ssh.

Настройка прав доступа и ssh-agent

Права на файлы — частая причина отказа. Приватный ключ должен иметь chmod 600 (только владелец читает/пишет), публичный — 644. Каталог ~/.ssh/ — 700. Неправильные разрешения SSH игнорирует ключ из безопасности.

На клиенте: chmod 700 ~/.ssh, chmod 600 ~/.ssh/id_*, chmod 644 ~/.ssh/id_*.pub. Если серверный authorized_keys (для вашего Git-сервера), то тоже 600. ssh-agent должен видеть ключ: после ssh-add -l показывается отпечаток.

Для Git Bash на Windows:

1. eval "$(ssh-agent -s)".
2. ssh-add ~/.ssh/id_rsa.
3. ssh -T git@github.com.

Если на сервере: Проверьте /etc/ssh/sshd_config — PasswordAuthentication yes, если нужно fallback, и restart sshd.

Список команд для прав:

• chmod 700 ~/.ssh — каталог.
• chmod 600 ~/.ssh/id_rsa — приватный ключ.
• chmod 644 ~/.ssh/id_rsa.pub — публичный.
• ssh-add -D — очистить agent, если глючит.

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

Убедитесь, что remote-URL в SSH-формате: git@github.com:username/repo.git. HTTPS не подойдет для ключей — проверьте git remote -v. Если wrong URL, git remote set-url origin git@github.com:username/repo.git.

Частые ошибки: ключ добавлен в wrong аккаунт GitHub, несколько ключей в agent (ssh-add -D и добавьте нужный), или known_hosts конфликтует (удалите строку с github.com: ssh-keygen -R github.com). На Ubuntu после clone добавляется IP — это нормально, но ключ решает.

Таблица ошибок и фиксов:

• Очистите known_hosts при смене IP: ssh-keygen -R "192.30.253.112".
• Для нескольких аккаунтов: ~/.ssh/config с Host gitub-work.
• Нюанс: В corporate firewall может блокироваться порт 22 — используйте 443 с ProxyCommand.

Когда проблема глубже: серверная сторона и альтернативы

Если клиент настроен, но ошибка на вашем Git-сервере — смотрите sshd_config. Убедитесь, PubkeyAuthentication yes, AuthorizedKeysFile .ssh/authorized_keys. Перезапустите sudo systemctl restart sshd.

Права на серверном ~/.ssh/authorized_keys — 600, владелец root или user. Лог sshd (/var/log/auth.log) покажет детали: “invalid key” или “permission denied”. Для GitLab или Bitbucket шаги похожи, но добавляйте ключ в их UI.

Это покрывает 95% случаев. Остальное — кастомные config или passphrase в ключе (ssh-agent поможет). Подумайте о deploy-keys для repo-specific доступа или passkey в новых версиях SSH.