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

Завршите уобичајеним случајем: проверен хост, заштићен пренос, намерно изабран метод аутентификације и никакво непотребно прослеђивање. Та комбинација је одговор на питање из наслова, и то су четири одлуке, а не једна.