Ang passphrase ng SSH key ay nagpoprotekta sa file, hindi sa ruta

May backup disk mula sa lumang laptop na naglalaman pa rin ng pribadong SSH key, at may nagtatanong kung pinoprotektahan ito ng VPN. Hindi, at hindi kailanman. Pinoprotektahan ng VPN ang landas sa pagitan ng dalawang network; pinoprotektahan ng passphrase ang file; pinoprotektahan ng agent ang tumatakbong session. Tatlong magkaibang mekanismo, tatlong magkaibang paraan ng pagpalya, at ang nakaw na kopya ay nag-aalala lamang sa unang dalawa.

Ang passphrase ay pag-aari ng file

Ini-encrypt ng passphrase ng SSH key ang materyal ng pribadong key habang nakapahinga. Hindi ito ang password ng account na ipinapadala sa server, at hindi ito ang kredensyal na ginagamit upang sumali sa VPN. Ang paghahalo sa kanila ay humahantong sa mga pagbabagong hindi tumutugon sa pagkakalantad.

Ang manwal ng ssh-keygen ng OpenSSH ay sumasaklaw sa paghawak ng mga passphrase, kasama ang switch na -p na nagtatakda ng bagong passphrase sa key na mayroon na.

Para sa umiiral na key ang anyo ng utos ay simple, at muling isinusulat nito ang file:

ssh-keygen -p -f ~/.ssh/id_ed25519

Gamitin ang aprubadong proseso ng pagpapanatili at pagbawi ng may-ari ng key, dahil ito ay pagsulat, hindi pagsusuri. Huwag ilathala ang pribadong file at huwag maglagay ng tunay na passphrase sa pinagsasaluhang command line. Ang pagpapalit ng passphrase ay hindi muling nag-e-encrypt ng kopyang kinuha kanina. Itala ang lokasyon ng lumang kopya sa ticket upang makapagpasya ang may-ari kung sisirain ito.

Ang kopya ay nabubuhay nang mas matagal kaysa sa laptop at sa tunel

Kapag nakopya na ang file ng key, wala nang sinasabi ang aktibong koneksyon ng VPN ng laptop tungkol dito. Ang mahalaga ay kung gaano kahusay na protektado ang file mismo, at kung aling mga server ang nagtitiwala pa rin sa katugmang pampublikong key.

Ang pagpapalit ng passphrase sa kasalukuyang file ay hindi gumagalaw sa kopya, at hindi nag-aalis ng parehong pampublikong key mula sa authorized_keys sa isang server. Ang pagbawi at muling pag-encrypt ay magkaibang aksyon.

Kaya ituring ang tumagas na pribadong key bilang pangyayari sa pagkakakilanlan, hindi pangyayari sa network. Alisin o palitan ang tinanggap na key sa pamamagitan ng mga server at proseso ng pagpapatala na nagmamay-ari nito. Ang paghinto sa VPN ay naglilimita sa isang ruta sa isang sandali; hindi ito pagbawi.

Ang pag-unlock ay naglilipat ng lihim sa agent

Nagtatago ang agent ng mga na-decrypt na pagkakakilanlan para sa susunod na pagpapatotoo, kaya hindi na kailangang i-type muli ng user ang passphrase sa bawat koneksyon. Ito ay kaginhawahan na may sariling hangganan ng seguridad.

Maaaring limitahan ng ssh-agent kung gaano katagal nananatiling load ang isang pagkakakilanlan sa pamamagitan ng opsyon na -t, at ang setting para sa isang pagkakakilanlan ay maaaring lumampas sa limitasyong iyon. Piliin ang patakaran para sa agent na talagang pinapatakbo mo sa halip na ipagpalagay na ang pagkadiskonekta sa VPN ay nakakalimot sa bawat load na key.

Ang prosesong nakompromiso pagkatapos ma-unlock ang key ay ibang problema kaysa sa nakaw na naka-encrypt na file. Ang pag-forward ng agent sa ibang host ay nagtatalaga ng kakayahan sa pagpapatotoo nang hindi kinokopya ang file ng key, kaya paganahin lamang ito para sa aprubadong pangangailangan.

Ilista ang hawak ng agent sa ngayon bago at pagkatapos ng pagbabago:

ssh-add -l

Ang mga trabahong walang pagmamatyag ay nangangailangan ng sariling plano

Hindi makasasagot ang naka-iskedyul na trabaho sa isang prompt. Kailangan nito ng aprubadong kaayusan sa kredensyal ng makina, at ang pagtatago ng lihim ng pag-unlock sa parehong direktoryo ng key, nababasa ng parehong account, ay hindi lumilikha ng ikalawang hangganan.

Makipagtulungan sa may-ari ng serbisyo sa suportadong paghahatid ng lihim o pagpapatakbo gamit ang hardware, at saklawin ang pag-renew, pagpalya at pagbawi. Ang paghahangad na may tao sa keyboard ay nagbabago sa hitsura ng pagpalya kumpara sa host na nagbuboot nang walang nagmamatyag.

Panatilihin din ang pagsusuri ng pagkakakilanlan ng host sa server at ang mga paghihigpit sa account nito. Ang ruta ng VPN ay nagbibigay ng pribadong landas; hindi nito pinatutunayan na ang bawat tagapakinig ng SSH na naaabot mo ay ang host na nilayon mo. Itala ang tagapakinig at ang fingerprint ng key ng host sa parehong imbentaryo ng key mismo.

I-verify ang mga hangganan nang hiwalay

Subukan ang bawat hangganan sa sarili nitong tanong. Nabubuksan ba ang file nang walang passphrase? Hawak pa rin ba ng agent ang pagkakakilanlan pagkatapos ng pagkadiskonekta? Tumatanggap pa rin ba ang server ng pampublikong key?

Dalawang utos ang sumasagot sa una at ikatlo:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Itala ang proteksyon ng file, pinapayagang paggamit ng key at pag-alis sa panig ng server bilang tatlong hiwalay na linya. Ang tunel, passphrase at agent ay bawat isa ay nagbabantay ng ibang bahagi ng ugnayan, at isa lamang sa kanila ang tungkol sa network.