Аутентифікація на основі SSH: відомі_хости та авторизовані ключі

Я читав про налаштування ключів ssh в Linux і маю кілька питань. Виправте мене, якщо я помиляюся…

Скажімо, хост tr-lgto хоче підключитися до хосту tr-mdm за допомогою ssh. Якщо ми хочемо бути впевнені, що це справжній tr-mdm, ми генеруємо пару ключів на tr-mdm і додаємо відкритий ключ до known_hoststr-lgto. Якщо tr-mdm хоче перевірити, що це справжнє tr-lgto, то tr-lgto повинен створити ключ, і додати відкритий ключ до authorized_keystr-mdm.

Питання 1 : У файлі unknown_hosts немає поля користувача , лише IP-адреси та імена хостів. tr-mdm може мати багато користувачів, кожен з яких має власну .sshпапку. Чи слід додати відкритий ключ до кожного з known_hostsфайлів?

Питання 2 : Я виявив, що ssh-keyscan -t rsa tr-mdmповерне відкритий ключ tr-mdm. Як я можу знати, якому користувачеві належить цей ключ? Більше того, відкритий ключ у /root/.ssh/відрізняється від того, що повертає ця команда. Як це може бути?

Ви змішуєте аутентифікацію серверної машини на клієнтській машині та автентифікацію користувача на серверній машині.

Аутентифікація сервера

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

Клієнт може перевірити, чи відомий той сервер, а не якийсь ізловмисний сервер, який намагається передати його як правильний. SSH надає лише простий механізм для перевірки легітимності сервера: він запам'ятовує сервери, до яких ви вже підключились, у ~/.ssh/known_hostsфайлі на клієнтській машині (також є загальносистемний файл /etc/ssh/known_hosts). Під час першого підключення до сервера вам потрібно перевірити, чи відкритий ключ, представлений сервером, є відкритим ключем сервера, до якого ви хотіли підключитися. Якщо у вас є відкритий ключ сервера, до якого ви збираєтесь підключитися, ви можете додати його ~/.ssh/known_hostsна клієнті вручну.

Аутентифікацію сервера потрібно зробити перед тим, як надіслати на нього будь-які конфіденційні дані. Зокрема, якщо автентифікація користувача передбачає пароль, пароль не повинен надсилатися на неавторизований сервер.

Аутентифікація користувача

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

• Користувач може представити пароль для облікового запису, в який він намагається увійти; сервер потім перевіряє правильність пароля.
• Користувач може представити відкритий ключ і довести, що він має приватний ключ, пов'язаний з цим відкритим ключем. Це точно той самий метод, який використовується для аутентифікації сервера, але зараз користувач намагається довести свою особу, а сервер їх перевіряє. Спроба входу приймається, якщо користувач доведе, що він знає приватний ключ, а відкритий ключ знаходиться в списку авторизації облікового запису ( ~/.ssh/authorized_keysна сервері).
• Інший тип методу передбачає делегування частини роботи щодо автентифікації користувача на клієнтській машині. Це відбувається в контрольованих середовищах, таких як підприємства, коли багато машин мають однакові рахунки. Сервер аутентифікує клієнтську машину за тим самим механізмом, який використовується навпаки, а потім покладається на клієнта для аутентифікації користувача.

Друзі дали мені відповідь. За замовчуванням ключ ідентифікує машину, а не користувача. Отже, ключі зберігаються в / etc / ssh /. Ось чому я отримав інший ключ від того, що зберігається в /root/.ssh