Как SSH-ключ на локальном ПК спас от блокировки в GitLab из-за потери двухфакторной аутентификации
Разработчик потерял доступ к приложению-аутентификатору при переносе на новый Android и обнаружил, что выбраться из блокировки в GitLab можно с помощью SSH-ключа, привязанного к аккаунту.
Двухфакторная аутентификация защищает аккаунт — но только до тех пор, пока вы не потеряете доступ к самому аутентификатору. В GitLab есть запасной путь через SSH-ключи, и он реально работает.
Что случилось
Разработчик Марио Гарсия рассказал историю, с которой сталкивался, наверное, каждый, кто использует двухфакторную аутентификацию (2FA). Он переносил приложение-аутентификатор на другой смартфон на Android, попытался сменить резервный пароль — и в итоге потерял доступ ко всем учётным записям, которые были привязаны к этому приложению.
Ситуация банальная: при миграции аутентификатора на новое устройство что-то пошло не так, и вместо плавного переноса он получил блокировку. Пришлось отключать 2FA на всех сервисах и настраивать заново.
В чём проблема с GitLab
На большинстве сервисов восстановление после потери 2FA — рутинная процедура. Обычно хватает резервных кодов или подтверждения по почте. Но у Марио не оказалось резервных кодов от GitLab, а получить шестизначный код подтверждения по email в тот момент не получалось.
GitLab предлагает два способа восстановить доступ при потере 2FA:
- Код по электронной почте — самый простой вариант, но не всегда доступен
- Генерация новых резервных кодов через SSH-ключ, привязанный к аккаунту
Второй вариант и оказался спасительным.
Как это работает
Марио заранее настроил SSH-ключ для аутентификации и подписи коммитов в GitLab — это хорошая практика, которую он рекомендует всем. Именно этот ключ, хранившийся локально на компьютере, позволил обойти блокировку.
Процедура занимает всего несколько шагов:
Сначала нужно убедиться, что на машине есть SSH-ключи. Обычно они лежат в папке ~/.ssh и называются id_rsa или id_ed25519.
Затем выполняется команда:
ssh -i ~/.ssh/id_ed25519 git@gitlab.com 2fa_recovery_codes
Она генерирует новые резервные коды. Один из них копируется, после чего на странице входа в GitLab вводятся логин, пароль и этот код — и доступ восстановлен.
После этого рекомендуется заново настроить 2FA и обязательно сохранить резервные коды в надёжном месте.
Почему это важно
Эта история — хороший пример того, что резервные механизмы восстановления действительно нужны. Двухфакторная аутентификация значительно повышает безопасность, но создаёт новую точку отказа: если вы потеряете доступ к аутентификатору без резервных кодов, вы можете потерять и доступ к сервису.
SSH-ключ как средство восстановления — это неочевидная, но надёжная страховка. Он хранится локально, не зависит от приложений и не привязан к конкретному устройству. Для разработчиков, которые и так используют SSH для работы с репозиториями, это практически бесплатная дополнительная защита.
Впрочем, важно понимать: этот механизм работает именно в GitLab. Другие сервисы имеют собственные процедуры восстановления, и полагаться на единый подход ко всем аккаунтам не стоит.
Практический вывод
Если вы используете GitLab и до сих пор не настроили SSH-ключ — самое время. Это не только упростит ежедневную работу с репозиториями, но и даст запасной путь на случай потери доступа к аутентификатору. А резервные коды от 2FA стоит хранить не в аутентификаторе, а в отдельном надёжном месте — например, в менеджере паролей или на зашифрованном носителе.
Мелочь? Да. Но именно мелочи решают, когда «что-то пошло не так».