Чому автентифікація ключа SSH краща, ніж автентифікація пароля?


45

Це не стільки технічне питання, скільки концептуальне. Я розумію, що криптовалюта, що використовується в ключі SSH, набагато сильніше, ніж звичайний пароль, але я не розумію, чому це вважається більш безпечним.

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

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

Я щось неправильно зрозумів, чи це поважні побоювання?


10
Зробіть і те, і інше - ключ, для якого потрібно пароль. Таким чином потрібно визначити дві речі, а не одну. Ви також можете легко визнати недійсними втрачені ключі та мати декілька авторизованих ключів для більшого контролю над цим тощо.
Фоші

2
Це, мабуть, має бути перенесено до безпеки.

10
@DKGasser: Ні, не повинно. Тут ідеально правильне питання. Тільки тому, що щось можна перенести на інший веб-сайт, це не означає, що воно повинно .
Wuffers

4
@DKGasser: Це може перейти на цей сайт, це абсолютно правильне питання. Але тут також є вагомим питанням, тому немає ніяких причин мігрувати його. Якби це питання було знято з теми тут, то так, його можна було б перенести туди. Але це повністю на темі на цьому сайті, і тому його не слід мігрувати.
Wuffers

3
І не забувайте, ключ SSH ніколи не переходить через мережу. Віддалений сервер НІКОЛИ не отримує ключ, на відміну від пароля, який не тільки надсилається по мережі, але надсилається на віддалений сервер. Подумайте про це наступного разу, коли ви не будете впевнені, який пароль використовувати, і спробуйте кілька ..., які, можливо, використовуються в інших облікових записах! Які паролі ви надіслали на цей сервер ???
9mjb

Відповіді:


40

Якщо ваша служба SSH дозволяє перевірити автентифікацію на основі пароля, ваш бот-мереж день і ніч буде забитий підключеним до Інтернету, намагаючись відгадати імена користувачів та паролі. Бот-сітка не потребує інформації, вона може просто спробувати популярні імена та популярні паролі. Є дуже багато людей на ім'я Джон з паролем qwerty123. Крім усього іншого, це засмічує ваші журнали.

Якщо ваша служба SSH дозволяє лише автентифікацію відкритого ключа, зловмиснику потрібна копія приватного ключа, що відповідає відкритому ключу, що зберігається на сервері. Вони не можуть робити випадкові атаки, вони повинні мати попередні знання ваших користувачів і мати можливість викрасти приватний ключ з ПК авторизованого користувача вашого SSH-сервера.

Те, що приватні ключі часто захищені довгою фразою, має другорядне значення.

Оновлення:

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

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

Також http://xkcd.com/538/

Безпека


7
+1, за винятком того, що автентичний відкритий ключ нічого не зробить для того, щоб ваші журнали забилися ботами, які намагаються підключитися. Щоб зупинити це, запустіть свій SSH-сервер на високому порті (тобто 9876 замість 22). Тоді, якщо вони хочуть вдарити вас, вони спочатку повинні портирувати вас, і боти, як правило, не витрачають стільки часу ... Є 22 сервери SSH на 22.
Ex Umbris

3
Ви не жартуєте на розмір журналу - мій / var / log / secure пішов від мегабайт спроб входу, до кілобайт (з моїми записами для входу).
Джон C

2
+1 Цікаво, що я працюю з автором на основі пароля .., як 10 років зараз .. хаха .. Звичайно, мої публічно відкриті порти ssh ніколи не портують 22. Подумайте, що ботнети будуть сканувати мене і намагатимуться перешкоджати кожному порт вони можуть ?? Хороша інформація, дякую.
Джеймс Т Снелл

2
@ExUmbris, а не зміну порту, слід розглянути можливість використання fwknop: Авторизація одного пакета та стукування порту . Перевага тут повинна бути очевидною: коли ви не дозволяєте нікому навіть бачити, що порт відкритий де завгодно, якщо їм не надали доступ до порту через стукання SPA, вони навіть не можуть спробувати знайти його за допомогою nmap та експлуатувати його. Це набагато краще, ніж проста безпека через неясність.
aculich

@aculich Зміна порту - це не "безпека через неясність". Все, що я роблю, - це запобігання заповненню журналів попередженнями. Однак у вас є вагомий момент щодо покращення безпеки через SPA.
Ex Exbrbris

8

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

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

Я вважаю, що також можна захистити паролем SSH ключі.


Варто зауважити, що спроби змушування паролів проти sshd можна виявити та захистити від них (наприклад, від fail2ban), тоді як той, хто вкрав ваш приватний ключ, може спробувати паролі на ньому так само швидко, як його комп'ютер (або кластер) дозволить їх. Це все ще не є чудовою атакою , але вони значно покращили свої шанси порівняно з розумною політикою fail2ban.
Xiong Chiamiov


1

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

Ви маєте рацію, що незашифрований ключ може зчитуватися з жорсткого диска, якщо комп'ютер викрадений - тому зашифруйте його паролем.

Якщо ваш комп'ютер порушений зловмисним програмним забезпеченням, ви заповнені файлами незалежно .. - хтось може отримати зашифрований ключ і заблокувати ваш пароль.


1
Примітка: але ви не можете зашифрувати свій ключ паролем, якщо він буде використовуватися програмно (тобто в сценарії).
TheStoryCoder
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.