У меня есть репозиторий Github, к которому я хочу получить доступ с двух разных Linux-машин.
За первой машиной я следил Инструкции на Github для генерации ключей SSH и добавил полученный открытый ключ в Github. Этот клиент работает нормально.
Для второго клиента я скопировал /home/{user}/.ssh/id_rsa файл от первого клиента. Я подумал, что это все, что мне нужно сделать, но когда я пытаюсь подключиться, я получаю «Permission denied (publickey)».
Что мне не хватает?
Один и тот же ключ SSH должен использоваться несколькими клиентами. У меня есть разные ключи SSH для разных сетей, и они фактически хранятся на зашифрованном USB-накопителе, который я без проблем использую с нескольких разных компьютеров.
SSH очень требователен к разрешениям файлов, поэтому сначала я бы проверил все разрешения из /home/{user} вплоть до id_rsa сам файл.
SSH на самом деле не заботится о разрешениях на запись группы или мира, поэтому убедитесь, что вы chmod go-w ваш домашний каталог и ~/.ssh каталог для начинающих. Я бы также убедился, что они принадлежат вашему пользователю chown ${USER}:${USER}.
Для самого ключа SSH я chmod 600 их...
Если хотите, у меня есть дополнительная информация о том, как я управляю своими ключами SSH в моем ответ к другому вопросу SSH.
Если вы получаете отказ в разрешении со стороны Github, возможно, он получает не ваш скопированный файл ключа SSH, а систему по умолчанию. Легкий способ обойти это - ~/.ssh/config файл и поместите в него следующее:
Host github.com
Hostname github.com
User git
IdentityFile ~/.ssh/yourkeyfile
Это заставит ваш SSH-клиент использовать этот ключ только для github.com.
Надеюсь это поможет.
Я знаю, что это старый, но подумал, что хочу указать, что вам также нужно скопировать общественный ключ ко второму клиенту
(или пересчитайте его с помощью ssh-keygen -y -f ~ / .ssh / id_rsa_ ..> ~ / .ssh / id_rsa ... pub)
С 1]:
Метод аутентификации с открытым ключом: «открытый ключ»
Единственное ТРЕБУЕМОЕ "имя метода" аутентификации - "publickey".
аутентификация. Все реализации ДОЛЖНЫ поддерживать этот метод;
однако не всем пользователям нужны открытые ключи, и большинство локальных
политики вряд ли потребуют аутентификации с открытым ключом для всех
пользователей в ближайшее время.При использовании этого метода владение закрытым ключом служит
аутентификация. Этот метод работает путем отправки созданной подписи
с закрытым ключом пользователя. Сервер ДОЛЖЕН проверить, что ключ
является действительным аутентификатором для пользователя и ДОЛЖЕН проверять, что
подпись действительна. Если оба удерживаются, запрос аутентификации ДОЛЖЕН быть
принято; в противном случае он ДОЛЖЕН быть отклонен. Обратите внимание, что сервер МОЖЕТ
требуют дополнительных аутентификаций после успешной аутентификации.
Ваш ssh-клиент начинает аутентификацию, отправляя на сервер открытый ключ (подпись выделена жирным шрифтом выше). Сервер, если открытый ключ является авторизованным, отправляет вашему клиенту случайный идентификатор сеанса. Затем ваш клиент кодирует этот идентификатор сеанса закрытым ключом и отправляет его обратно на сервер. Сервер декодирует этот идентификатор сеанса с помощью открытого ключа и, если он соответствует исходному идентификатору сеанса, аутентифицирует вашего клиента.
Вероятно, это потому, что вы не скопировали разрешение файла на втором клиенте.
Но закрытый ключ частный, правильный способ - создать новый закрытый ключ на втором клиенте, а затем добавить его открытый ключ в Github