У мене є репо Github, до якого я хочу отримати доступ з двох різних машин Linux.
Для першої машини я дотримувався вказівок Github щодо генерації SSH ключів і додав отриманий відкритий ключ до Github. Цей клієнт працює чудово.
Для другого клієнта я скопіював /home/{user}/.ssh/id_rsaфайл з першого клієнта. Я подумав, що це може бути все, що я повинен зробити, але коли я намагаюся підключитися, я отримую "Дозвіл відмовлено (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 ... паб)
З [1]:
Метод аутентифікації відкритого ключа: "publickey"
Єдина ПОТРІБНА автентифікація 'ім'я методу' - це «
автентифікація publickey» . Усі реалізації ОБОВ'ЯЗКОВО підтримують цей метод;
однак, не всі користувачі повинні мати відкриті ключі, і більшість локальних
політик, швидше за все, не потребуватимуть автентифікації відкритих ключів для всіх
користувачів найближчим часом.При цьому методі володіння приватним ключем служить
аутентифікацією. Цей метод працює, надсилаючи підпис, створений
приватним ключем користувача. Сервер ПОВИНЕН перевірити, чи ключ
є дійсним аутентифікатором для користувача, і ОБОВ'ЯЗКОВО перевірити, чи
підпис дійсний. Якщо обидва утримуються, запит на аутентифікацію ОБОВ'ЯЗКОВО
прийняти; в іншому випадку ОБОВ'ЯЗКОВО відхилити. Зауважте, що сервер МОЖЕ
потребувати додаткових аутентифікацій після успішної аутентифікації.
Ваш ssh-клієнт починає аутентифікацію, надсилаючи відкритий ключ (підпис, на який посилається жирним шрифтом), на сервер. Сервер, якщо відкритий ключ є авторизованим ключем, відправляє назад випадковий ідентифікатор сеансу вашому клієнту. Потім ваш клієнт кодує цей ідентифікатор сеансу приватним ключем і повертає його назад на сервер. Сервер розшифровує цей ідентифікатор сеансу за допомогою відкритого ключа, а якщо він відповідає оригінальному ідентифікатору сеансу, то аутентифікує вашого клієнта.
Можливо, тому, що ви не скопіювали дозвіл на файл на другому клієнті.
Але приватний ключ приватний , правильний спосіб - створити новий приватний ключ на другому клієнті, а потім додати його відкритий ключ до Github