Kiu vere vidas vian SSH-pasvorton en nefidinda VPN?

Pasigu SSH-sesion tra VPN, kiun vi ne mem administras, kaj la pasvorto ankoraŭ apartenas al la SSH-servilo, ne al la reto inter ili. Se la transporto al kontrolita gastiganto estas ĝuste protektita, pasiva observanto sur tiu vojo ne ricevas la pasvorton en legebla formo. Sed ŝanĝu unu kondiĉon, kaj la respondo ŝanĝiĝas: nekontrolita gastiganto, malfortigita listo de ĉifroj aŭ kompromitita laborstacio ĉiuj produktas malsamajn rezultojn. Faru la subajn kontrolojn laŭ ordo, kaj traktu ĉiun kiel haltan kondiĉon.

Nomu la ricevanton antaŭ ol tajpi ion ajn

La pasvorta kampo vojaĝas ene de aŭtentikiga mesaĝo, kaj tiu mesaĝo vojaĝas ene de la ĉifrita transporto. Konfideco estas eco de la transporto, kio signifas, ke ĝi dependas de tio, ĉu protekto estis intertraktita kaj ĉu ĝi estis intertraktita kun la gastiganto, kiun vi celis. Ĝuste tiun duan duonon homoj preterlasas. Konekto ĉifrita al trompanto estas samtempe konfideca kaj senutila. La ensaluto al la VPN pruvas nenion pri la SSH-gastiganto, kaj la reputacio de la provizanto ne anstataŭas la ŝlosilan kontrolon.

Tenu la du direktojn aparte en la kapo. La gastiga ŝlosilo respondas, al kiu servilo vi alvenis. Pasvorta aŭ ŝlosila aŭtentikigo respondas, kiun uzanton la servilo akceptas. Plibonigi la duan neniam riparas la unuan.

Kontrolu la gastigan identecon, la rikordon kaj la intertraktadon

Komencu ĉe la kliento per la rikordo, kiun vi jam havas. Publikigita fingrospuro komparita kun fidinda fonto, kaj known_hosts-enskribo, kiu ankoraŭ kongruas, donas al vi la solan pruvon, kiu gravas antaŭ ol komenciĝas aŭtentikigo.

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

Ĉe la servila flanko, presu la fingrospurojn, kiujn vi intencas publikigi, anstataŭ kopii ilin el memoro. Disdoni ilin ekster la kanalo estas la tuta senco; fingrospuro algluita el la sama babilkanalo kiel la gastiga nomo pruvas nur, ke ambaŭ venis el la sama loko.

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

La intertraktitaj algoritmoj venas el la komunaĵo de ambaŭ flankoj. Se klienta agordo fiksas eksdatajn ŝlosilinterŝanĝojn por atingi malnovan aparaton, tiu elekto validas por ĉiu gastiganto, kun kiu ĝi parolas, do limigu ĝin al tiu gastiganto anstataŭ tutmonde.

Legu la metodojn, kiujn la servilo efektive akceptas

Scii, kiujn aŭtentikigajn metodojn servilo permesas, diras al vi, por kio la pasvorto entute estas. Gastiganto, kiu akceptas nur publikajn ŝlosilojn, havas neniun pasvortan interŝanĝon por protekti, kaj gastiganto, kiu ankoraŭ akceptas pasvortojn, meritas konscian decidon anstataŭ hereditan defaŭlton.

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

Ŝanĝi uzanton al ŝlosila aŭtentikigo forigas la pasvorton de tiu uzanto el tiu interŝanĝo. Tio ne faras kompromititan laborstacion sekura, kaj ĝi ne faras nefidindan malproksiman sesion sendanĝera. Tiuj estas malsamaj riskoj kun malsamaj regiloj. Decidu ankaŭ pri agenta plusendo. Plusendi agenton al nefidinda gastiganto donas al tiu gastiganto la kapablon uzi viajn ŝlosilojn dum la sesio daŭras, kaj tio estas pli granda elmetiĝo ol la pasvorta demando, per kiu ĉio komenciĝis.

Traktu averton pri gastiga ŝlosilo kiel incidentan paŝon

Kiam la kliento avertas, ke la gastiga identigo ŝanĝiĝis, haltu kaj kontrolu per kanalo, kiu ne iras laŭ la sama reta vojo. Komparu la fingrospuron kun la servila konzolo aŭ kun la operatoro, kiu rekonstruis ĝin. Forviŝi la malnovan enskribon por silentigi la averton estas la unu ago, kiun vi devus rifuzi. Ĝi forĵetas la pruvon kaj transformas eblan interkaptadon en normalan ensaluton.

Se la gastiganto estis laŭleĝe rekonstruita, forigu la eksdatan enskribon nur post kiam la nova fingrospuro estas konfirmita, poste rekonektu kaj rekontrolu la intertraktadon. Registru la ŝanĝon kun la dato kaj la kialo, ĉar la sekva persono vidos la saman averton kaj devas scii, ke ĝi estis solvita.

Kion ĉi tiu gvidilo ne kovras

VPN-operatoro, kiu observas trafikon, ne estas la sama afero kiel programaro kun lokaj privilegioj sur via maŝino. Kompromitiĝo de la finpunkto, malamika retumila etendo aŭ klavara registrilo staras sub ĉio, kion SSH povas intertrakti, kaj neniu tunelo tion ŝanĝas. Se la laborstacio estas suspektinda, sekvu la incidentan proceduron anstataŭ testi sekretecon rekonektante tra alia eliro. Rekonekto pruvas, ke la reta vojo ŝanĝiĝis, kaj nenion pri la finpunkto.

Finu per la ordinara kazo: kontrolita gastiganto, protektita transporto, la aŭtentikiga metodo, kiun vi celkonscie elektis, kaj neniu plusendo, kiun vi ne bezonis. Tiu kombinaĵo estas la respondo al la demando en la titolo, kaj ĝi estas kvar decidoj anstataŭ unu.