При Authentication failed или HTTP 403 сначала выполните git remote -v и проверьте две вещи: в какой репозиторий идёт push и есть ли у текущей учётной записи право записи. GitHub больше не принимает пароль аккаунта для Git-операций по HTTPS. Используйте personal access token через менеджер учётных данных либо настройте SSH-ключ. Никогда не вставляйте токен в URL, код, скриншот или сообщение.
Коммиты готовы, git status чистый, но git push просит пароль или отвечает 403. Кажется, что сломан Git, хотя соединение уже состоялось: сервер понял запрос, но не принял удостоверение или не разрешил запись. Частая причина особенно проста: remote указывает на чужой учебный репозиторий, который вы клонировали для чтения.
Смотрим git remote -v, владельца репозитория и протокол HTTPS или SSH.
Уточняем активную учётную запись, разрешение на запись, срок токена и SSO организации.
Удаляем только неверную сохранённую запись и авторизуемся через token или SSH.
Чем Authentication failed отличается от HTTP 403
Оба сообщения связаны с доступом, но указывают на разные этапы. Authentication failed чаще означает, что сервер не принял предоставленное удостоверение: устаревший пароль, отозванный токен или неверную сохранённую запись. Код 403 означает, что запрос распознан, но действие запрещено: у пользователя нет write-доступа, токен не имеет нужного разрешения или доступ организации ограничен SSO.
| Симптом | Вероятная зона | Первая проверка |
|---|---|---|
Authentication failed | Учётные данные | Аккаунт, token и сохранённый credential |
403 при push | Авторизация | Право write и владелец remote |
Repository not found | Адрес или доступ | git remote -v и видимость репозитория |
Permission denied (publickey) | SSH | Ключ, агент и аккаунт GitHub |
| Push защищённой ветки отклонён | Правило ветки | Разрешённый workflow и pull request |
Push проходит адрес, удостоверение, право на репозиторий и правило ветки.
Собираем безопасную диагностику remote и текущей ветки
Начните с команд, которые не показывают секреты. Адрес remote можно читать и исправлять, имя ветки определяет цель push, а конфигурация credential helper подсказывает, где система хранит авторизацию. Не выполняйте git config --list --show-origin в публичной переписке целиком: пользовательские настройки иногда содержат приватные адреса.
git status
git branch --show-current
git remote -v
git remote get-url origin
git config --get credential.helper
# HTTPS выглядит так:
# https://github.com/OWNER/REPOSITORY.git
# SSH выглядит так:
# git@github.com:OWNER/REPOSITORY.git
# После проверки владельца и точного адреса:
git push -u origin YOUR_BRANCH- Точный OWNER/REPOSITORY и совпадает ли он с проектом, куда вы вправе отправлять код.
- Протокол remote: HTTPS и SSH используют разные способы удостоверения.
- Имя текущей ветки и не защищена ли целевая ветка правилами репозитория.
Оба маршрута безопасны при корректном хранении секрета, но диагностируются по-разному.
Выбираем HTTPS с token или SSH-ключ
Оба способа подходят для обычной работы. HTTPS проще начать и удобно интегрируется с менеджером учётных данных: при входе вместо пароля используется personal access token, а современный helper может открыть браузер. SSH один раз связывает публичный ключ с аккаунтом и затем подписывает подключение локальным закрытым ключом. Не смешивайте диагностику протоколов.
| Вариант | Что хранится локально | Когда удобен |
|---|---|---|
| HTTPS + credential manager | Token в защищённом хранилище | Первый GitHub-проект и вход через браузер |
| HTTPS + fine-grained token | Token с ограниченным доступом | Нужны точные репозитории и разрешения |
| SSH | Закрытый ключ на машине | Регулярная работа и несколько push |
| Deploy key | Ключ одного репозитория | Автоматизация, а не личная работа |
| Пароль аккаунта | Не подходит | GitHub не принимает его для Git по HTTPS |
.pub, token и коды восстановления нельзя отправлять даже помощнику.Практика: исправляем push по HTTPS без утечки token
Предположим, remote правильный и у вашего аккаунта есть write-доступ. Тогда нужно обновить сохранённую авторизацию. Используйте системный менеджер учётных данных или официальный клиент, удаляя только запись GitHub для неверного аккаунта. Следующий push запустит новый вход. Если репозиторий принадлежит организации, проверьте, нужно ли отдельно разрешить token через SSO.
- Откройте репозиторий в браузере под нужной учётной записью и убедитесь, что можете видеть Settings или создавать ветку согласно своей роли.
- Сверьте OWNER/REPOSITORY из адресной строки с выводом
git remote get-url origin. - Если это ваш fork, замените origin только на точный URL fork командой
git remote set-url origin .... - Откройте системный Credential Manager или Keychain и удалите только устаревшую запись для github.com, если она привязана не к тому аккаунту.
- Повторите push и завершите официальный браузерный вход либо используйте token вместо пароля в защищённом запросе.
- После успеха обновите страницу веток GitHub и проверьте SHA последнего коммита, а не только отсутствие ошибки в терминале.
- Push сообщает имя ветки и переданный диапазон объектов без Authentication failed или 403.
- На GitHub появилась нужная ветка с тем же последним коммитом.
- Token не оказался в remote URL, истории shell, файлах проекта или скриншотах.
Точный текст ошибки помогает не менять token, когда проблема находится в remote или правах.
Почему новый token не помогает и что ещё проверить
Создание ещё одного token не исправит неправильный remote, отсутствие роли или правило защищённой ветки. Fine-grained token действует только для выбранных репозиториев и разрешений. В организациях SAML SSO может требовать отдельной авторизации доступа. При нескольких аккаунтах credential manager способен снова подставить старую запись.
Он попадает в конфигурацию, историю и логи. Храните секрет через credential manager и сразу отзывайте случайно раскрытый token.
user.name подписывает коммит, но не определяет аккаунт, которым сервер авторизует push.
Читать публичный репозиторий можно без права записи. Направьте origin на свой fork, а upstream оставьте для получения обновлений.
Проверьте выбранные repositories, Contents write и требования организации, не расширяя права без необходимости.
Ошибка может требовать ветку и pull request. Следуйте правилу репозитория, а не меняйте авторизацию.
Можно ли вводить пароль GitHub для git push по HTTPS?
Нет. Используйте personal access token или браузерный вход через credential helper.
Что первым показывает git remote -v?
Адрес репозитория и протокол, через который выполняются fetch и push.
Связан ли git config user.name с аккаунтом для push?
Нет. Эти данные записываются в авторство коммита, а серверная аутентификация выполняется отдельно.
Почему 403 возможен с правильным token?
У аккаунта или token может не быть write-доступа к выбранному репозиторию, организации или ветке.
Что делать с случайно опубликованным token?
Немедленно отозвать его в GitHub, создать новый с минимальными правами и удалить утечку из доступных мест.
Основные команды и безопасный рабочий цикл собраны в курсе Git. Тренируйтесь в отдельном учебном репозитории, где ошибку remote можно увидеть без риска для рабочего кода.
Затем откройте Git и GitHub для новичков, настройте работу с ветками и сохраните пошаговый материал как загрузить проект на GitHub.