Хто насамрэч бачыць ваш пароль 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, і ніякі тунель гэтага не змяняе. Калі працоўная станцыя падазроная, ідзіце па працэсе інцыдэнту, а не правярайце сакрэтнасць, перападключаючыся праз іншы выхад. Перападключэнне даказвае, што сеткавы шлях змяніўся, і нічога не даказвае пра канчатковы пункт.

Скончыце звычайным выпадкам: правераны хаст, абаронены транспарт, свядома абраны метад аўтэнтыфікацыі і ніякай перадачы, якая вам не патрэбна. Гэтая камбінацыя і ёсць адказ на пытанне ў загалоўку, і гэта чатыры рашэнні, а не адно.