Sino talaga ang nakakakita ng iyong SSH password sa isang VPN na hindi pinagkakatiwalaan?

Ipadala ang sesyon ng SSH sa isang VPN na hindi ikaw ang namamahala, at ang password ay pag-aari pa rin ng SSH server, hindi ng network sa gitna. Kung maayos na protektado ang transport papunta sa isang beripikadong host, hindi nakukuha ng isang pasibong tagamasid sa landas na iyon ang password sa anyong nababasa. Pero baguhin ang isang kondisyon, at magbabago ang sagot: isang hindi beripikadong host, isang pinahinang listahan ng cipher, o isang komprometidong workstation ay lahat nagbibigay ng magkakaibang resulta. Gawin ang mga pagsusuri sa ibaba nang sunud-sunod, at ituring ang bawat isa bilang kondisyon ng paghinto.

Pangalanan ang tatanggap bago mag-type ng kahit ano

Ang field ng password ay naglalakbay sa loob ng isang mensahe ng pagpapatunay, at ang mensaheng iyon ay naglalakbay sa loob ng naka-encrypt na transport. Ang pagiging kompidensyal ay katangian ng transport, ibig sabihin nakadepende ito sa kung napagkasunduan ang proteksyon at kung napagkasunduan ito sa host na nilayon mo. Iyon ang ikalawang kalahati na nilalaktawan ng mga tao. Ang koneksyong naka-encrypt sa isang manloloko ay kompidensyal at walang silbi nang sabay. Ang pag-login sa VPN ay walang pinapatunayan tungkol sa SSH host, at ang reputasyon ng provider ay hindi kapalit ng pagsusuri ng susi.

Panatilihing hiwalay sa isipan ang dalawang direksyon. Ang susi ng host ang sumasagot kung aling server ang naabot mo. Ang pagpapatunay sa password o susi ang sumasagot kung aling user ang tinatanggap ng server. Ang pagpapabuti ng pangalawa ay hindi kailanman nag-aayos ng una.

Suriin ang pagkakakilanlan ng host, ang talaan at ang negosasyon

Magsimula sa kliyente sa talaang mayroon ka na. Ang nailathalang fingerprint na inihambing sa isang pinagkakatiwalaang pinagmulan, at ang entry sa known_hosts na tumutugma pa rin, ang nagbibigay sa iyo ng tanging ebidensyang mahalaga bago magsimula ang pagpapatunay.

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

Sa panig ng server, i-print ang mga fingerprint na balak mong ilathala sa halip na kopyahin ang mga ito mula sa memorya. Ang ipamahagi ang mga ito sa labas ng channel ang buong punto; ang fingerprint na idinikit mula sa parehong chat channel ng hostname ay nagpapatunay lamang na pareho silang galing sa isang lugar.

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

Ang napagkasunduang algorithm ay nagmumula sa interseksyon ng dalawang panig. Kung ang konfigurasyon ng kliyente ay nagpupin ng lipas nang palitan ng susi para maabot ang lumang device, ang pagpipiliang iyon ay nalalapat sa bawat host na kausap nito, kaya limitahan ito sa host na iyon sa halip na pandaigdigan.

Basahin ang mga paraang aktwal na tinatanggap ng server

Ang pag-alam kung aling mga paraan ng pagpapatunay ang pinapayagan ng server ay nagsasabi sa iyo kung para saan ang password. Ang host na tumatanggap lamang ng pampublikong susi ay walang palitan ng password na poprotektahan, at ang host na tumatanggap pa rin ng password ay karapat-dapat sa sadyang desisyon sa halip na minanang default.

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

Ang paglipat ng user sa pagpapatunay sa susi ay nag-aalis ng password ng user na iyon sa palitang iyon. Hindi nito ginagawang ligtas ang komprometidong workstation, at hindi nito ginagawang walang pinsala ang hindi pinagkakatiwalaang malayuang sesyon. Iba’t ibang panganib ang mga ito na may iba’t ibang kontrol. Magpasya rin tungkol sa pagpapasa ng ahente. Ang pagpapasa ng ahente sa isang host na hindi pinagkakatiwalaan ay nagbibigay sa host na iyon ng kakayahang gamitin ang iyong mga susi habang tumatagal ang sesyon, at mas malaking paglantad ito kaysa sa tanong ng password na pinagmulan ng lahat.

Ituring ang babala sa susi ng host bilang hakbang ng insidente

Kapag nagbabala ang kliyente na nagbago ang pagkakakilanlan ng host, huminto at iberipika sa pamamagitan ng channel na hindi dumadaan sa parehong landas ng network. Ihambing ang fingerprint sa console ng server o sa operator na muling nagtayo nito. Ang pagbura ng lumang entry para patahimikin ang babala ang tanging aksyong dapat mong tanggihan. Itinatapon nito ang ebidensya at ginagawang ordinaryong login ang posibleng pagharang.

Kung lehitimong itinayo muli ang host, alisin ang lumang entry pagkatapos lamang makumpirma ang bagong fingerprint, pagkatapos ay kumonekta muli at suriin muli ang negosasyon. Itala ang pagbabago kasama ang petsa at dahilan, dahil makikita ng susunod na tao ang parehong babala at kailangang malaman na naayos na ito.

Ano ang hindi saklaw ng gabay na ito

Ang operator ng VPN na nanonood ng trapiko ay hindi katulad ng software na may lokal na pribilehiyo sa iyong makina. Ang kompromiso sa endpoint, isang galit na extension ng browser o isang keyboard logger ay nasa ilalim ng lahat ng maaaring pagkasunduan ng SSH, at walang tunnel ang makapagbabago niyon. Kung pinaghihinalaan ang workstation, sundan ang proseso ng insidente sa halip na subukan ang pagiging lihim sa pamamagitan ng muling pagkonekta sa ibang labasan. Ang muling pagkonekta ay nagpapatunay na nagbago ang landas ng network at wala tungkol sa endpoint.

Tapusin sa karaniwang kaso: beripikadong host, protektadong transport, ang paraan ng pagpapatunay na sadyang pinili mo, at walang pagpapasang hindi mo kailangan. Ang kombinasyong iyon ang sagot sa tanong sa pamagat, at ito ay apat na desisyon hindi isa.