Хто насправді бачить ваш пароль SSH у недовіреному VPN?

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

Назвіть одержувача, перш ніж щось вводити

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

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

Перевірте ідентичність хоста, запис і узгодження

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

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

Прочитайте методи, які сервер справді приймає

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

Розглядайте попередження про ключ хоста як крок інциденту

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

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

Чого цей посібник не охоплює

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

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