Чому автентифікація пароля SSH є ризиком безпеки?

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

Існують плюси та мінуси для автентифікації на основі pw або ключа.

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

Все зводиться до цього: Коли ви робите автентифікацію на основі ключів, ви повинні захистити свій ключ парольною фразою. Якщо у вас не працює ssh-агент (ssh-agent не позбавляє вас кожного разу вводити свою парольну фразу), ви нічого не отримуєте з точки зору зручності. Безпека є суперечливою: вектор атаки зараз перемістився з сервера на ВАС, або ваш рахунок, або вашу особисту машину, (...) - це може бути, а може і не простіше зламати.

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

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

Використання ssh клавіш має одну унікальну функцію порівняно з входом до пароля: ви можете вказати дозволені команди. Це можна зробити, змінивши ~/.ssh/authorized_keysфайл на сервері.

Наприклад,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

дозволить лише команду `/usr/local/bin/your_backup_script.sh" з цим конкретним ключем.

Ви також можете вказати дозволені хости для ключа:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Або поєднайте два:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

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

Ви можете отримати найкраще з обох світів, лише дозволивши автентифікацію пароля з вашої мережі. Додайте наступне до кінця sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

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

Порівняйте також довжину пароля з розміром ключа (зазвичай це тисячі біт).

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

ssh-клавіші запобігають нападу людини на посередництво на ваш пароль.

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

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

з паролем вони мали б ваші облікові дані.

Моє рішення - мати переносний ключ ssh у відповідних форматах на зашифрованому розділі на ключі usb. це дозволяє мені:
легко витягнути цей ключ у разі його втрати.
обмежте, до яких серверів він дозволяє мені отримувати доступ
і досі переношу його

хоча встановлення програмного забезпечення для монтування - це біль (truecrypt)

Це компроміс, як каже @MartinVejmelka.

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

У паролі є такі проблеми:

• Якщо він короткий, це може бути жорстоко змушеним
• Якщо він довгий, його легко забути
• Це може бути серфінг на плечі

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

Тут уже згадуються хороші моменти.

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

Мене нещодавно попередив Нортон про завантаження інсталятора Zombee Mod (не банку, а інсталятора) для додавання польоту в банку Minecraft. Я переглянув деталі, і Нортон перерахував багато утиліт на цьому сайті, який був позначений як містить троян. Я не знаю, правильно це чи ні, але це було досить специфічно з назви файлів. Відомий також факт, що трояни вводяться в (деякі) варези до їх розповсюдження.

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

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

Якщо ви не вважаєте, що це важливо, спробуйте зареєструвати всі шкідливі спроби входу, які ви отримаєте на наступний тиждень. На моєму комп’ютері - абсолютно звичайному настільному ПК - за останній тиждень було понад 4000 спроб відгадати мій пароль і майже 2 500 спроб взлому. Скільки тисяч випадкових здогадок, на вашу думку, пройде, перш ніж зловмисник натрапить на ваш пароль?

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

Метод аутентифікації Passwd справді небезпечний (imho). За допомогою цього механізму пароль буде переданий на sshd-сервер (як @ramon вже сказав). Це означає, що деякі люди можуть змінити sshd-сервер для отримання пароля. З атакою "Людина в середині" це дуже легко здійснити в локальній мережі.

Ви можете просто виправити сервер sshd, встановивши цей патч ( https://github.com/jtesta/ssh-mitm ). Використовуйте arpspoofта iptablesрозміщуйте свій виправлений сервер між клієнтом та справжнім сервером sshd.

Будь ласка, відключіть авторизацію пароля: відкрийте файл конфігурації /etc/ssh/ssh_configта додайте рядок PasswordAuthentication no.

Ви можете обійти -o StrictHostKeyChecking=noопцію. Це дуже корисно при використанні ssh в сценарії оболонки.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost