O cale de administrare bazată pe Tor pentru VPS-ul dvs.

01Protejați administrarea, precum și finalizarea comenzii

Comandarea unui server printr-un browser protejat nu protejează automat o sesiune ulterioară SSH. O autentificare directă poate dezvălui adresa dvs. sursă către server și rețelele de pe traseu. Decideți cum va funcționa administrarea înainte de prima conexiune, inclusiv accesul de urgență în cazul în care ruta preferată eșuează.

Tor poate ascunde IP-ul direct al clientului față de destinație, dar nu este un remediu pentru acreditările reutilizate, datele de configurare care vă identifică sau orice atac de corelare a traficului. De asemenea, adaugă latență. Obiectivul util este o cale de administrare consecventă, a cărei comportament îl înțelegeți și îl puteți verifica.

02Începeți cu un client Tor local funcțional

Un daemon Tor de sistem oferă de obicei SOCKS pe 127.0.0.1:9050, în timp ce Tor Browser folosește de obicei 9150. Verificați configurația dvs. reală în loc să presupuneți oricare dintre porturi. Aplicația trebuie să își trimită conexiunea prin acel proxy; deschiderea Tor Browser nu direcționează fiecare program de pe computer.

Pe sistemele acceptate, torsocks împachetează aplicații precum SSH și direcționează apelurile de rețea acceptate prin Tor. Testați configurația cu o adresă exemplu doar pentru documentație, înlocuită cu adresa reală a serverului dvs. Comanda următoare presupune un daemon Tor de sistem în execuție și un cont administrativ dedicat.

torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]

03Faceți ruta parte din configurația SSH

Pentru utilizarea regulată, o configurație per gazdă reduce șansa de a uita un wrapper. Exemplul de mai jos folosește o implementare netcat cu suport pentru proxy SOCKS5. Implementările diferă, așa că confirmați opțiunile -x și -X în versiunea instalată și verificați dacă rezolvarea numelui de gazdă este la distanță.

IdentitiesOnly limitează cheile oferite serverului; împerecheați-o cu o cheie nouă folosită pentru acest proiect. Verificați și păstrați amprenta cheii de gazdă a serverului printr-un canal de provisioning de încredere. Tor schimbă calea de rețea, dar autentificarea gazdei SSH rămâne esențială.

Host silent-admin
    HostName 203.0.113.45
    User admin
    IdentityFile ~/.ssh/silentvps_ed25519
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

04Mutați SSH în spatele unui serviciu onion

Un endpoint onion permite administrarea fără un port SSH accesibil public și evită folosirea unei ieșiri Tor pentru această conexiune. Instalați și configurați Tor pe server, apoi mapați un port virtual onion către serviciul SSH local. Exemplul este o configurație de pornire; căile și comenzile serviciului variază în funcție de distribuție.

După ce Tor creează directorul serviciului, recuperați în mod privat fișierul său de nume de gazdă și testați o conexiune prin proxy-ul clientului. Păstrați private cheile de identitate ale serviciului onion. Numai după o autentificare independentă reușită ar trebui să restricționați SSH la localhost și să eliminați accesul public. Verificați că consola dvs. de recuperare funcționează înainte de a face această modificare.

HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22

05Adăugați autorizarea clienților pentru un endpoint privat

Fără autorizare suplimentară, oricine află adresa onion poate ajunge la serviciu și la promptul său SSH. Autorizarea clienților Tor v3 adaugă o poartă criptografică separată: serviciul deține cheia publică a clientului autorizat, iar clientul deține cheia privată corespunzătoare.

Urmați instrucțiunile actuale ale proiectului Tor pentru formatele cheilor și directorul authorized_clients. Verificați că un client neautorizat nu se poate conecta. Păstrați și autentificarea prin cheie SSH și planificați cum să revocați autorizarea unui dispozitiv pierdut fără a vă pierde propriul acces rămas.

06Testați DNS și evitați scurgerea identității

O căutare de nume de gazdă făcută de resolverul local poate dezvălui ținta înainte ca conexiunea să ajungă la proxy. Folosirea IP-ului serverului pentru o destinație clearnet evită acea căutare anume; numele onion necesită rezolvare în interiorul Tor. Pentru alte nume de gazdă, confirmați comportamentul remote-DNS al aplicației în loc să vă bazați pe o setare generică de proxy.

Sistemul invitat poate păstra în continuare momente de autentificare, nume de utilizator și intrări de jurnal. Analizați intenționat păstrarea lor în loc să dezactivați orbește fiecare diagnostic. De asemenea, inspectați numele de gazdă locale, metadatele commit-urilor și configurația copiată pentru detalii identificatoare. Tor nu le elimină pe acestea din traficul aplicației.

• Folosiți o cheie dedicată și un flux de lucru de proiect izolat.
• Verificați portul SOCKS așteptat și comportamentul remote DNS.
• Păstrați accesul de recuperare și o a doua autentificare testată înainte de a schimba listenerii.
• Examinați serviciul Tor și SSH după actualizări.
• Nu partajați niciodată cheile de identitate onion sau secretele de autorizare ale clientului.

07Mențineți sesiunile lungi și întreținerea viitoare practice

Rulați lucrări administrative lungi în tmux sau screen, astfel încât o întrerupere a conexiunii să nu distrugă sesiunea. Circuitele Tor și condițiile de rețea se pot schimba, așa că păstrați comenzile repetabile și înțelegeți cum să le reluați. O cantitate mică de latență suplimentară este mai ușor de tolerat când întreținerea este planificată.

Același model onion poate sta în fața unui dashboard local sau a unui serviciu Git privat. Fiecare aplicație are totuși nevoie de autentificare, actualizări de software și configurare atentă. Continuați să folosiți ruta protejată pentru asistență, reînnoire și copii de rezervă acolo unde cerințele dvs. de confidențialitate o impun; consecvența contează la fel de mult ca configurarea inițială.