Ключ Ssh прийнятий хостом, але відключенням клієнта

Гело,

У мене проблема з SSH після встановлення Fedora 23.

Коли я не хочу підключитися до віддаленого хоста приватним ключем, мій хост знайде ключ:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Але як ви бачите, як мій клієнт відключається сам

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Я можу підключитися до свого хоста за допомогою шпаклівки на Windows, використовуючи той самий приватний ключ, і я можу з'єднатися зі своїм телефоном, використовуючи інший приватний ключ.

У вас є ідея?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Дякую

Редагувати: я можу підключитися за допомогою пароля

Перш за все, в Інтернеті доступні численні, дуже добре написані докладні документи про те, як налаштувати або налаштувати аутентифікацію на основі відкритих ключів . Будь ласка, подивіться на одну з них і перевірте, чи правильно ви дотримувалися всього. Ось один. Тому я не збираюсь повторювати це знову.

Сама основна концепція (скопійована звідси ):

Аутентифікація на основі ключів використовує два ключі, один "відкритий" ключ, який може бачити кожен, і інший "приватний" ключ, який може бачити лише власник. Щоб надійно спілкуватися за допомогою аутентифікації на основі ключів, потрібно створити пару ключів, надійно зберігати приватний ключ на комп’ютері, з якого хочеться увійти, і зберегти відкритий ключ на комп'ютері, на який він хоче увійти.

Тепер із журналу налагодження ви опублікували:

• Здається, задіяні два різні користувачі. /home/theo/.ssh/authorized_keysі /home/tbouge/.ssh/id_rsa. Ви намагаєтесь увійти як один користувач у домашній каталог іншого користувача?
• Помилка Postponed publickey for theo..означає, що небажаний метод аутентифікації був випробуваний перед методом publick key. SSH буде випробовувати кожен метод автоматизації, включений у config, один за одним. У вашому випадку ви GSSAPIAuthentication yesввімкнули те, що не використовуєте. Ви можете сміливо відключити це, зробивши GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodшвидше за все, він не може обробити файл приватного ключа (або дозвіл файлу, або проблема з іменем). SSH дуже чутливий до дозволів до директорій та файлів як на локальних, так і віддалених комп'ютерах. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Отже, переконайтеся, що ваші встановлені правильно. Дивіться це: /unix/131886/ssh-public-key-wont-send-to-server

• Щодо третьої помилки: Permission denied (public key).є кілька речей, які потрібно перевірити.

  • Неправильне ім'я користувача
  • Неправильна пара ключів

  • Неправильний цільовий хост

    • Ось докладніші відомості: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-інстанція .

Наступна частина трохи заплутана:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Щоб зрозуміти це краще, давайте пройдемо процес аутентифікації поетапно, як описано тут у digitalocean :

1. Клієнт починає з надсилання ідентифікатора для тієї ключової пари, з якою він хотів би підтвердити автентифікацію на сервер.
2. Сервер перевіряє файл дозволеного_кейсу облікового запису, який клієнт намагається увійти для ідентифікатора ключа.
3. Якщо у файлі знайдеться відкритий ключ із відповідним ідентифікатором, сервер генерує випадкове число і використовує відкритий ключ для шифрування номера.
4. Сервер надсилає клієнту це зашифроване повідомлення.
5. Якщо клієнт насправді має пов'язаний приватний ключ, він зможе розшифрувати повідомлення за допомогою цього ключа, виявивши оригінальний номер.
6. Клієнт поєднує розшифрований номер із загальним ключем сеансу, який використовується для шифрування зв'язку, і обчислює хеш MD5 цього значення.
7. Потім клієнт відправляє цей хеш MD5 назад на сервер як відповідь на зашифроване повідомлення про номер.
8. Сервер використовує той самий ключ спільного сеансу та оригінальний номер, який він надіслав клієнтові, щоб самостійно обчислити значення MD5. Він порівнює власний розрахунок з тим, який клієнт відправив назад. Якщо ці два значення відповідають, це доводить, що клієнт мав приватний ключ і клієнт має автентифікацію.

У вашому випадку, як бачите, віддалений комп'ютер лише прийняв ваш public key, зашифрував пакет із цим ключем і відправив його назад на клієнтський комп'ютер. Тепер клієнтському комп’ютеру потрібно довести, що він має право private key. За допомогою лише потрібного private_key він може розшифрувати отримане повідомлення та надіслати відповідь назад. У цьому випадку клієнт цього не робить, і процес аутентифікації закінчується без успіху.

Я сподіваюся, що це допоможе вам зрозуміти проблеми та вирішити їх.

Правильні привілеї у файлах ssh?

.ssh папка -> 700

відкритий ключ -> 644

приватний ключ -> 600

Також перевірте користувача та групу

Ви кажете, що у вас є однаковий ключ на машині Windows; ви впевнені, що файл приватного ключа, який ви маєте на вашій машині Linux, правильний? Можливо, приватний ключ у форматі putty, який ssh ​​не розуміє легко. У будь-якому випадку, якщо я покладу неправильний або недійсний файл приватного ключа, я отримаю точно таку ж помилку, яку ви маєте.

Щоб виправити проблему, правильніше було б генерувати новий ключ на машині Linux, а не повторно використовувати ключ з іншої машини. Ви можете просто додати новий відкритий ключ до файлу санкціонованих ключів на хості, а потім можете використовувати як ключ Windows від Windows, так і новий ключ Linux від Fedora.

Ваша проблема, здається, досить поширена, і також ясна, я можу сказати.

 Permission denied (publickey).

це щось означає для вас? для мене це дуже багато означає.

чи можете ви перевірити на сервері, чи є у вас запущений selinux в примусовому режимі pls? якщо не скажіть мені, в який режим працює selinux.

Крім того, якщо ви можете зробити ще одну спробу і захопити журнали аудиту цієї спроби та опублікувати тут, це обов'язково скаже нам, чому:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Це проблема з дозволом зрозуміла, але не має дозволу на файл :-)

Здається, проблема (в моєму випадку ...) була викликана типом ключа.

Я щойно вирішив це, додавши до локального ~/.ssh/configфайлу (клієнтська машина Fedora 23) наступне :

PubkeyAcceptedKeyTypes=+ssh-dss

Хоча я додав цей рядок і до сервера, і до конфігураційного файлу клієнта, лише різниця клієнта змінила значення. Зауважте, що права доступу повинні 600бути прочитані для конфігураційного файлу.

Я не знаю, чи є ще хтось із цією проблемою, але я нарешті вирішив цю проблему для своєї однієї машини (ноутбука), яка відчувала цю проблему. Я вважаю, що знаю, що врешті-решт розібрало це, і я залишу інформацію тут, сподіваючись, що це допоможе всім, хто ще може зіткнутися з цим, - а також, щоб хтось сподівався перевірити моє рішення та підтвердити, що це насправді те, що вирішив проблему.

Як виявляється, проблема взагалі була (для мене) не з SSH, а з тим, як PAM налаштовував мої ключі. Конфігурація в /etc/pam.dзастарілому (хоча вона працювала належним чином через Fedora 22), і в результаті правильних речей не було зроблено під час входу [більше], щоб забрати мої ключі $HOME/.ssh/. Запуск цієї команди:

# sudo authconfig --updateall

відновив конфігурацію /etc/pam.d належним чином. Під час наступної перезавантаження, коли я ввійшов у систему, коли я перший раз спробував перейти на свій сервер, діалогове вікно попросило мене ввести свою парольну фразу для мого ключа ssh ( $HOME/.ssh/id_rsa). Я зробив це, встановив прапорець "Автоматично розблокувати при вході" і voila! Моя здатність вибиватися з ноутбука була відновлена.

Фон

Підказка, яка привела мене до вирішення цього питання, з'явилася, коли я імпортував ключ RSA із зовнішнього джерела. (Ключ USB я носити з собою, з моїм ключем «віддалений доступом» для моєї домашньої мережі. Я вимкнув PasswordAuth моїх звернені назовні серверних роки тому після вторгнення.) Після того, як ssh-add-ний ТОГО ключ RSA, в відміну від того , хто сидить в $HOME/.ssh/id_rsa, це було прийнято віддаленим сервером без проблем.

Тоді я закінчив робити те, що повинно було бути зайвим ssh-add, щоб забрати $HOME/.ssh/id_rsa. Я помітив, що після того, як я це зробив, ssh-add -lбуло два записи для одного ключа:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Зверніть увагу, як одна з двох записів не відображає ідентифікатор ключа, а лише ім’я файлу приватного ключа, що відповідає його підпису. Ніби приватний ключ насправді не був розблокований менеджером керування ключами .

Я вважаю, що саме це і відбувалося, і PAM передавав «погані ключі» агенту SSH, який не був розблокований парольною фразою. Отже, коли ssh намагалася пройти автентифікацію за допомогою ключа, насправді у нього не було (розблокованої) приватної половини пари ключів, і тому автентифікація не вдалася.

Останній біт - це гіпотеза, але незалежно від того, якщо у когось виникають проблеми з ключами ssh, які не приймаються віддаленими хостами (там, де раніше) після оновлення до F23, відновлення /etc/pam.d/каталогу з використанням authconfigварто спробувати вирішити.

Перевірте дозволи домашнього каталогу користувача. Це важливо. Повинно бути 755. 700 або 770 не працюватимуть.

У ваших ssh_config, спробуйте розкоментувати і / або додавання / видалення / додавання або до Cipher, Ciphersабо MACsлінії (ів).

Мені здається, що sshdпотрібно шукати певний шифр, який не включається до запиту, який можна додати, налаштувавши його у свій ssh_config.

... і я припускаю, що ви жодним випадком не PubkeyAuthenticationвстановили noна віддалений сервер, тому що це, безумовно, призведе до цього невдачі.