Wa sjocht eins jo SSH-wachtwurd op in net fertroude VPN?

Stjoer in SSH-sesje oer in VPN dat jo net sels beheare, en it wachtwurd heart noch altyd ta de SSH-server, net ta it netwurk der tuskenyn. As it transport nei in ferifiearre host goed beskerme is, kriget in passive waarnimmer op dat paad it wachtwurd net yn lêsbere foarm. Mar feroarje ien betingst, en it antwurd feroaret: in net ferifiearre host, in ferswakke syferslist of in kompromittearre wurkstasjon jouwe allegear oare útkomsten. Doch de kontrôles hjirûnder yn folchoarder, en behannelje elk as in stopbetingst.

Neam de ûntfanger foardat jo eat type

It wachtwurdfjild reizget binnen in autentikaasjeboade, en dy boade reizget binnen it fersifere transport. Fertroulikheid is in eigenskip fan it transport, wat betsjut dat it ôfhinget fan oft beskerming úthannele is en oft dat dien is mei de host dy’t jo bedoelden. Krekt dy twadde helte slaan minsken oer. In ferbining fersifere nei in bedrager is tagelyk fertroulik en nutteloas. De VPN-oanmelding bewiist neat oer de SSH-host, en de reputaasje fan de provider is gjin ferfanging foar de kaaikontrôle.

Hâld de twa rjochtingen apart yn jo holle. De hostkaai beantwurdet hokker server jo berikt hawwe. Wachtwurd- of kaaiautentikaasje beantwurdet hokker brûker de server akseptearret. It ferbetterjen fan it twadde makket it earste nea goed.

Kontrolearje de hostidentiteit, it record en de ûnderhanneling

Begjin op de klant mei it record dat jo al hawwe. In publisearre fingerôfdruk ferlike mei in betroubere boarne, en in known_hosts-ynfier dy’t noch past, jouwe jo it iennige bewiis dat foar de autentikaasje ta saak docht.

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

Druk op de serverkant de fingerôfdrukken ôf dy’t jo fan plan binne te publisearjen, ynstee fan se út it ûnthâld te kopiearjen. Se bûten it kanaal ferspriede is krekt it punt; in fingerôfdruk dy’t út itselde petearkanaal plakt is as de hostnamme bewiist allinnich dat beide fan itselde plak komme.

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

De úthannele algoritmen komme út ’e krusing fan beide kanten. As in klantkonfiguraasje in ferâldere kaaie-útwikseling fêstset om in âld apparaat te berikken, jildt dy kar foar elke host dêr’t it mei praat, behein it dus ta dy host ynstee fan globaal.

Lês de metoaden dy’t de server eins akseptearret

Witte hokker autentikaasjemetoaden in server tastiet, fertelt jo wêr’t it wachtwurd eins foar is. In host dy’t allinnich publike kaaien akseptearret hat gjin wachtwurdútwikseling te beskermjen, en in host dy’t noch wachtwurden akseptearret fertsjinnet in bewuste beslissing ynstee fan in erflik standertwearde.

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

In brûker oersette nei kaaiautentikaasje hellet it wachtwurd fan dy brûker út dy útwikseling. It makket in kompromittearre wurkstasjon net feilich, en it makket in net fertroude ôfstânsessie net ûnskealik. Dit binne ferskate risiko’s mei ferskate kontrôles. Beslis ek oer agent-oerdracht. In agent oerdrage nei in net fertroude host jout dy host de mooglikheid om jo kaaien te brûken salang’t de sesje duorret, en dat is in gruttere bleatstelling as de wachtwurdfraach dêr’t it allegear mei begûn.

Behannelje in hostkaai-warskôging as in ynsidintstap

As de klant warskôget dat de hostidentifikaasje feroare is, stopje dan en ferifiearje fia in kanaal dat net troch itselde netwurkpaad giet. Ferlykje de fingerôfdruk mei de serverkonsôle of mei de operator dy’t it wer opboud hat. It âlde ynfier wiskje om de warskôging stil te meitsjen is de iene aksje dy’t jo wegerje moatte. It smyt it bewiis fuort en feroaret in mooglike ûnderskepping yn in gewoane oanmelding.

As de host legitiem wer opboud is, ferwiderje it ferâldere ynfier pas neidat de nije fingerôfdruk befêstige is, ferbyn dan opnij en kontrolearje de ûnderhanneling nochris. Registrearje de feroaring mei de datum en de reden, want de folgjende persoan sil deselde warskôging sjen en moat witte dat it oplost is.

Wat dizze runbook net dekt

In VPN-operator dy’t ferkear besjocht is net itselde as software mei pleatslike privileezjes op jo masine. Kompromitaasje fan it einpunt, in fijannige browserútwreiding of in toetseboerdlogger sitte ûnder alles wat SSH úthannejje kin, en gjin tunnel feroaret dat. As it wurkstasjon fertocht is, folgje dan it ynsidintsproses ynstee fan geheimhâlding te testen troch fia in oare útgong opnij te ferbinen. Opnij ferbinen bewiist dat it netwurkpaad feroare is en neat oer it einpunt.

Einigje mei it gewoane gefal: ferifiearre host, beskerme transport, de autentikaasjemetoade dy’t jo bewust keazen hawwe, en gjin oerdracht dy’t jo net nedich hiene. Dy kombinaasje is it antwurd op ’e fraach yn ’e titel, en it binne fjouwer besluten ynstee fan ien.