Cine vede cu adevărat parola ta SSH pe un VPN nesigur?

Trimite o sesiune SSH printr-un VPN pe care nu îl administrezi tu, iar parola rămâne a serverului SSH, nu a rețelei dintre ei. Dacă transportul către un host verificat este protejat corespunzător, un observator pasiv pe acea cale nu obține parola într-o formă lizibilă. Dar schimbă o condiție și răspunsul se schimbă: un host neverificat, o listă de cifruri slăbită sau o stație de lucru compromisă produc rezultate diferite. Rulează verificările de mai jos în ordine și tratează fiecare ca o condiție de oprire.

Numește destinatarul înainte de a tasta ceva

Câmpul parolei călătorește în interiorul unui mesaj de autentificare, iar acel mesaj călătorește în interiorul transportului criptat. Confidențialitatea este o proprietate a transportului, ceea ce înseamnă că depinde de faptul că s-a negociat protecție și că s-a negociat cu hostul pe care îl aveai în minte. Exact a doua jumătate este cea pe care oamenii o sar. O conexiune criptată către un escroc este confidențială și inutilă în același timp. Autentificarea în VPN nu dovedește nimic despre hostul SSH, iar reputația furnizorului nu înlocuiește verificarea cheii.

Ține cele două direcții separate în minte. Cheia hostului răspunde la ce server ai ajuns. Autentificarea prin parolă sau cheie răspunde la ce utilizator acceptă serverul. Îmbunătățirea celei de-a doua nu o repară niciodată pe prima.

Verifică identitatea hostului, înregistrarea și negocierea

Începe pe client cu înregistrarea pe care o ai deja. O amprentă publicată comparată cu o sursă de încredere și o intrare known_hosts care încă se potrivește îți dau singura dovadă care contează înainte de începerea autentificării.

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

Pe partea serverului, tipărește amprentele pe care intenționezi să le publici în loc să le copiezi din memorie. Distribuirea lor în afara canalului este tot rostul; o amprentă lipită din același canal de chat ca numele hostului dovedește doar că ambele vin din același loc.

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

Algoritmii negociați provin din intersecția ambelor părți. Dacă o configurație de client fixează un schimb de chei învechit pentru a ajunge la un dispozitiv vechi, acea alegere se aplică fiecărui host cu care vorbește, așa că limiteaz-o la acel host, nu global.

Citește metodele pe care serverul le acceptă cu adevărat

Să știi ce metode de autentificare permite un server îți spune la ce folosește parola. Un host care acceptă doar chei publice nu are niciun schimb de parole de protejat, iar un host care încă acceptă parole merită o decizie deliberată, nu o valoare implicită moștenită.

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

Trecerea unui utilizator la autentificarea prin cheie scoate parola acelui utilizator din acel schimb. Nu face o stație de lucru compromisă sigură și nu face o sesiune la distanță nesigură inofensivă. Sunt riscuri diferite cu controale diferite. Decide și despre redirecționarea agentului. Redirecționarea unui agent către un host nesigur îi dă acelui host capacitatea de a-ți folosi cheile cât durează sesiunea, iar asta este o expunere mai mare decât întrebarea despre parolă cu care a început totul.

Tratează un avertisment despre cheia hostului ca pe un pas de incident

Când clientul avertizează că identificarea hostului s-a schimbat, oprește-te și verifică printr-un canal care nu trece pe aceeași cale de rețea. Compară amprenta cu consola serverului sau cu operatorul care l-a reconstruit. Ștergerea intrării vechi pentru a reduce la tăcere avertismentul este singura acțiune pe care trebuie să o refuzi. Aruncă dovada și transformă o posibilă interceptare într-o autentificare obișnuită.

Dacă hostul a fost reconstruit în mod legitim, elimină intrarea învechită doar după confirmarea noii amprente, apoi reconectează-te și verifică din nou negocierea. Înregistrează schimbarea cu data și motivul, pentru că următoarea persoană va vedea același avertisment și trebuie să știe că a fost rezolvat.

Ce nu acoperă acest ghid

Un operator de VPN care observă traficul nu este același lucru cu un software cu privilegii locale pe mașina ta. Compromiterea punctului final, o extensie de browser ostilă sau un înregistrator de tastatură stau sub tot ce poate SSH să negocieze, iar niciun tunel nu schimbă asta. Dacă stația de lucru este suspectă, urmează procesul de incident în loc să testezi secretul reconectându-te prin altă ieșire. Reconectarea dovedește că calea de rețea s-a schimbat și nimic despre punctul final.

Încheie cu cazul obișnuit: host verificat, transport protejat, metoda de autentificare pe care ai ales-o intenționat și nicio redirecționare de care nu aveai nevoie. Această combinație este răspunsul la întrebarea din titlu, și sunt patru decizii, nu una.