При всіх антивирусах, мережевих моніторах на шлюзах і в самій ОС, системах превентивного виявлення вторгнень та інших заходах безпеки сервера або робочої станції, які годиною набувають параноїдальні ознаки - поставити 100% на те, що на машині немає, або чи не з'явиться в найближчому майбутньому, якийсь стукає хрени, неможливо.
Хтось може заперечити, мовляв "Так, але на приватний ключ можна поставити пароль!" - згоден, можна, але в такому випадку пароль буде зашитий в сам ключ, що при його крадіжці, а також достатніх обчислювальних ресурсах і хороших знаннях криптографії, дасть можливість для його активного брутфорса без будь-яких обмежень з боку ОС - тобто брутфорс ОС виконати набагато складніше (блокування доступу після 2-3 невдалих спроб входу, та ін.), ніж брутфорс ключа локально!
Також якщо буде втрачено приватний (id_rsa), то ми сміливо може помахати серванта ручкою і піти з горя синяви наклюкаццо (when SSH private keys are lost) якщо немає фізичного доступу до машини - публічний (id_rsa.pub) можна відновити з приватного, а ось приватний з публічного навряд чи. Є якась фіча відкликання (RevokedKeys) ключів, але це не одне і теж, що відновлення - відкликані (анульовані) ключі не можуть використовуватися для подальшої аутентифікації (Revoked keys can not be used for user or host authentication and will trigger a warning if used.) !
Тільки не кажіть, що злом SSL трафіку або брутфорс приватного RSA ключа неможливий - німці у Другу світову теж думали, що шифрувальну машину Енігма вермахту непереможна!
Якщо хто все ж наважився використати механізм SSH аутентифікації тільки на одних RSA ключах, з забороною парольного механізму, тоді виконуємо пару нескладних кроків, що описані нижче, а також пишемо заповіт, одягаємо памперси і тримаємо труселя міцніше !;)
Створення пари RSA ключів
Створення пари RSA ключів не займе багато часу - ssh-keygen-ім RSA ключі:
Тут ми увійшли в консоль як користувач "shaman", домашній каталог "/ home / shaman", в якому за замовчуванням розташований каталог .ssh з RSA ключами (id_rsa і id_rsa.pub). У прикладі пароль на приватний ключ не ставили, але для застосування на практиці бажано поставити хоч якийсь пароль на id_rsa (секретний ключ).
Зрозуміло всі описані тут маніпуляції, створення RSA ключів і т.п. виконуються на віддаленому сервері, на якому ми і збираємося проходити аутентифікацію по ключам.
Ключі можна створити і на локальній машині, але потім публічний ключ потрібно буде перенести на віддалену.
конфігурація sshd_config
Якщо зібралися відключити логін по паролю, тоді в / etc / ssh / sshd_config відключаємо:
PuTTY Unable to use key file
Для тих, хто в перший раз на лижах PuTTY - помилка "Unable to use key file" X: \ id_rsa "(OpenSSH SSH-2 private key)" може виникати з кількох причин:
- Неформат SSH версії в якій кувався id_rsa ключ і версії в якій він намагається використовуватися, для SSH-1 і SSH-2 ключі куються в різних форматах;
- Неформат id_rsa ключа для використання в PuTTY, для PuTTY потрібно ключі конвертувати в .ppk формат
Якщо id_rsa генерувався стандартними утилітами з пакету OpenSSH (ssh-keygen -t rsa), то для його використання в SSH клієнта PuTTY він повинен бути експортований в .ppk формат наступним чином (CMD варіант - puttygen id_rsa -o id_rsa.ppk):
- Запускаємо puttygen і завантажуємо туди наш id_rsa приватний ключ, що був створений утилітами з пакету OpenSSH, і, якщо хочемо, ставимо на нього пароль:
- Зберігаємо приватний ключ у форматі .ppk (Save private key):
Відновити публічний ключ від приватного
Для відновлення публічного ключа (Create a public SSH key from the private key) від уже наявного приватного виконаємо:
При такій конфігурації OpenSSH server for Windows ми можемо зіткнуться з помилкою SSH клієнта "OpenSSH Server refused our key", а системний журнал отримаємо повідомлення:
Чи не знайдено опис для події з кодом (0) в джерелі (sshd). Можливо, на локальному комп'ютері немає потрібних даних в реєстрі або файлів DLL повідомлень для відображення повідомлень віддаленого комп'ютера. Спробуйте використовувати ключ / AUXSOURCE = для отримання цього опису, - додаткові відомості про це містяться в довідці. У записі події міститься наступна інформація: sshd: PID 1712: error: Received disconnect from 192.168.231.1: 13: Unable to authenticate.
---
Чи не знайдено опис для події з кодом (0) в джерелі (sshd). Можливо, на локальному комп'ютері немає потрібних даних в реєстрі або файлів DLL повідомлень для відображення повідомлень віддаленого комп'ютера. Спробуйте використовувати ключ / AUXSOURCE = для отримання цього опису, - додаткові відомості про це містяться в довідці. У записі події міститься наступна інформація: sshd: PID 1712: Authentication refused: bad ownership or modes for directory / home / user.
Ймовірно, що помилку SSH клієнта "OpenSSH Server refused our key" будемо отримувати неминуче і постійно якщо будемо намагатися використовувати персональний файл ".ssh / authorized_keys" для кожного користувача!
Єдиним виходом в цьому випадку є використання загального, для всіх користувачів, файлу authorized_keys - "AuthorizedKeysFile / etc / ssh / authorized_keys".
Кожен користувач може створювати свої власні ключі, в своєму домашньому каталозі:
Але, для дозволу доступу по ключам тільки адміністратор повинен додати вміст публічного ключа (id_rsa.pub) кожного користувача в / etc / ssh / authorized_keys, ну, і зрозуміло не забуваємо додати користувача в / etc / passwd.