Чи виявляється ваш пароль SSH при спробі підключення до неправильного сервера?

192

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

ssh password

— vfclists
джерело

11

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

— jamesdlin

41

У ssh-клієнті спочатку ви автентифікуєте сервер і робите це так, що ви говорите "Я вірю, що я можу сказати свій пароль на цьому сервері". Наступного разу зверніть пильну увагу на повідомлення, яке ви побачили вперше: "Неможливо встановити справжність X. Відбиток ключа RSA - Y Ви впевнені, що Z? (Так / ні)" Це набридливе запитання не буде задано, якщо ви гадаєте автоматично відповідати так щоразу.

— kubanczyk

6

У PasswordAuthentication noOpenSSH можна встановити за замовчуванням і ввімкнути його лише (якщо / коли потрібно) для надійних серверів. У поєднанні з чіткою перевіркою ключів хостів це здебільшого повинно захищати вас від викриття пароля за звичайну ціну.

— варення

6

@kubanczyk, якщо ви хотіли SSH на "Internal-www.my-company.com", але випадково набрали "ssh www.my-company.com", це підказка не захистить вас - ймовірно, що обидва сервери у вашому довіреному списку це лише те, що одним із них керуєте ви, а іншим сторонні сторони.

— Марк

@hobbs ChallengeResponseAuthentication noтеж думаю

— ilkkachu

215

Простіше кажучи: так

Детальніше ...

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

Крім того, мені не обов'язково змінювати sshd, але я можу написати PAM-модуль (наприклад, використовуючи pam_script), який буде переданий вашим паролем.

Отже, так. НІКОЛИ не надсилайте свій пароль ненадійному серверу. Власник машини міг легко налаштувати його для реєстрації всіх спроб паролів.

(Насправді це не рідкість у світі infosec; налаштовуйте сервер медоносів для реєстрації спроб паролів)

— Стівен Харріс
джерело

13

Правильно. За замовчуванням стандарт sshdце НЕ паролі входу. (Якщо ви введете свій пароль як ім’я для входу, він буде зареєстрований, але це ще одна проблема). Стандарт sshd- це інструмент безпеки, і тому не входитимуть такі дані :-)

— Стівен Харріс

116

Ще одна причина використання пар публічних / приватних ключів ...

— Герріт

3

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

— vfclists

10

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

— рідний схід

44

Краща порада: ніколи не використовуйте auth пароль для ssh. Протокол має автентичний паблік із дуже вагомих причин; використай це!

— R ..

52

Так.

Пароль надсилається після встановлення зашифрованого з'єднання, але віддалений сервер отримує пароль у простому тексті.

Якщо ви переймаєтесь цим, найкращим і найпростішим рішенням є використання SSH-ключів.

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

Тепер, причина, яку пароль надсилається в простому тексті, полягає в тому, що він залишає всі рішення щодо обробки та зберігання його на віддалений кінець, і клієнт може бути абсолютно німим. Існує кілька різних форматів хешування (зберігання) паролів, які використовуються в системах Linux і BSD протягом останніх десяти років або близько того ( crypt (3) ), жоден з яких не потребує підтримки клієнта.

Хоча це частково і через історію (тобто завжди так було). Є кращі протоколи аутентифікації на відповідь на виклик, які можна використовувати навіть із паролями. Наприклад, SRP , який надає сторонам спільну таємницю під час аутентифікації. Він реалізований для деяких серверів SSH, але патч для OpenSSH призначений для (дуже) старої версії.

— ілкака
джерело

1

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

— kasperd

8

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

— Blacklight Shining

1

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

— Випадково832

де я можу побачити ті паролі, які використовуються для автентифікації? Їх немає в /var/log/auth.log, де тоді?

— アレックス

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

— musicinmybrain

10

Щоб побудувати на відповіді Стівена Харріса, ось створений нами в реальному часі вид, який показує, що змінений скрипт автентичності PAM міг би захопити при підключенні до коробки через ssh (сорт сот). Я використовую модифіковану версію бібліотеки PAM lib-storepw.

https://livesshattack.net

https://livesshattack.net/about

— Віллі С.
джерело

4

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

— Centimane

вона більше не працює, я надіслав величезну рядок як пароль, я думаю, що, можливо, її зламали, вибачте: - /

— scottydelta

@scottydelta Хоча я ще не заглянув у нього, можливо, обмеження буфера може бути або розміром пароля, який модуль PAM, або сам демон SSH можуть приймати при спробі аутентифікації. Сайт все ще працює так, як я його задумав, хоча і буде обробляти до межі буфера, прийнятого sshd або модулем PAM, якщо це дійсно так.

— Віллі С.

Чи є джерело для вашого зміненого lib-storepw доступним для інших?

— Тім Флетчер

2

SSH - це протокол, який вимагає взаємної довіри. Саме тому клієнт OpenSSH підтримує файл відомих_хостів, щоб реалізувати свою довіру за схемою першого використання.

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

— jvoorhis
джерело

SSH не вимагає взаємної довіри або, принаймні, не симетричної довіри. Важливо бути точним: unknown_hosts - це справжність, а не довіра. Як ви зазначаєте, розміщення відкритого ключа на менш надійному хості безпечно. Дійсно, використання пароля для входу є і "безпечним", якщо ви не використовуєте цей пароль. (Безумовно, це так само безпечно, як і ступінь, до якого ви довіряєте серверу.) Навіть логін, що базується на сервері, заснований на хості, залежить від асиметричного довіри.

— Маркхен