Синхронизация и много репозиториев

SSH-ключи

Настройки → Безопасность → SSH-ключи.

Почему этот раздел стоит рядом с токенами

Gitcito аутентифицирует две разные вещи, и люди вполне обоснованно считают, что это одно и то же:

Чем аутентифицируется
API хостинга — репозитории, пул-реквесты, задачи, проверки CI Вашим токеном
Транспорт git поверх https:// Вашим токеном, подставленным в URL
Транспорт git поверх git@… Вашим SSH-ключом, через системный ssh

Удалённый репозиторий вида git@github.com:me/api.git вообще не касается токена. Git передаёт соединение ssh, который никогда не слышал ни про какие персональные токены доступа. Это не экзотика — именно так и получается, когда репозиторий настраивал коллега, когда в .gitmodules прописаны git@-URL, когда компания отключила аутентификацию по HTTPS или когда хостинг — это самостоятельно развёрнутый GitLab.

Когда что-то идёт не так, ssh говорит Permission denied (publickey) и больше ничего. Формально верно, как совет — бесполезно.

Каждый ключ из ~/.ssh с типом, отпечатком и признаком того, держит ли его агент

Что показывает раздел

Для каждого ключа, найденного в ~/.ssh, показываются тип, размер, отпечаток и комментарий, плюс тот единственный факт, который объясняет большинство внезапных отказов:

в агенте / не в агенте. Ключ, которого агент не держит, не может ничего аутентифицировать, а агент забывает своё содержимое при перезагрузке, если ОС не сказали обратного. «Вчера же работало» — это обычно оно.

Что здесь можно сделать

Действие Что запускается
Копировать публичный ключ Кладёт строку .pub в буфер обмена — готово к вставке на любом хостинге
Добавить в агент ssh-add (с --apple-use-keychain на macOS, чтобы ключ пережил перезагрузку)
Загрузить на GitHub POST /user/keys с токеном этого профиля
Сгенерировать ключ ssh-keygen -t ed25519, с комментарием из вашей почты в git
Проверить соединение ssh -T git@<host>, переведённый на человеческий язык

Проверить соединение существует потому, что собственный ответ ssh вводит в заблуждение: GitHub успешно вас аутентифицирует и затем завершает работу с кодом ошибки, поскольку не даёт вам shell. Gitcito читает сообщение, а не код возврата, и показывает сырой вывод ниже, чтобы вы могли проверить его прочтение.

Ограничения, прямо и без прикрас

  • Загрузка работает только для GitHub. Для GitLab, Bitbucket и Azure DevOps доступны Копировать публичный ключ и ссылка прямо на страницу настроек ключей. Регистрация ключей на этих трёх не реализована, и кнопка не делает вид, что это не так.
  • Генерация никогда не перезаписывает. Имя, уже существующее в ~/.ssh, отклоняется. Молчаливая перезапись приватного ключа отзывает ваш доступ ко всему, что ему доверяет, и никакой диалог подтверждения этого не исправит.
  • Парольные фразы Gitcito не хранит. Вы вводите её при генерации или при добавлении в агент; она передаётся ssh-keygen/ssh-add и забывается. Сохранять её между перезагрузками — работа связки ключей ОС, через ssh-add.
  • Никакого редактирования ~/.ssh/config, никаких алиасов хостов, никакого выбора ключа для конкретного репозитория. Это живёт в вашей конфигурации ssh, и Gitcito этот файл не трогает.

Что никогда не покидает вашу машину

Gitcito никогда не читает, не показывает и не передаёт приватный ключ. Раздел перечисляет публичные половинки и отпечатки. Единственное, что вообще куда-либо отправляется, — это публичный ключ, для которого вы явно нажали Загрузить, и уходит он на GitHub, под вашим собственным токеном, после подтверждения, в котором назван отпечаток.

См. также: Безопасность и секреты · Хостинг и пул-реквесты

Улучшить этот перевод на GitHub