Кой всъщност вижда вашата 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 може да договори, и никакъв тунел не променя това. Ако работната станция е съмнителна, следвайте процеса за инциденти, вместо да изпитвате секретността, като се свързвате през друг изход. Повторното свързване доказва, че мрежовият път се е променил, и нищо за крайната точка.

Завършете с обикновения случай: проверен хост, защитен транспорт, метода за удостоверяване, който сте избрали нарочно, и никакво препращане, което не ви е нужно. Тази комбинация е отговорът на въпроса в заглавието и тя представлява четири решения, а не едно.