En Tor-baseret administrationssti til din VPS
Brug en SOCKS-proxy til SSH, udgiv et privat onion-endepunkt, og kontrollér DNS, godkendelse og gendannelse, før du lukker offentlig adgang.
Kort overblik
Tor kan ændre den netværkssti, der bruges til at nå en VPS, og et SSH onion-endpoint kan undgå en konventionel offentlig administrationsdestination. Ingen af tilgangene sikrer serveren automatisk. Beskyt SSH-nøgler, bekræft værtsidentitet, begræns adgang, og test konfigurationen, før du stoler på den.
Beskyt administration såvel som betaling
At bestille en server gennem en beskyttet browser beskytter ikke automatisk en senere SSH session. Et direkte login kan afsløre din kildeadresse for serveren og netværkene langs ruten. Beslut, hvordan administrationen skal fungere, før den første forbindelse, herunder nødadgang, hvis den foretrukne rute svigter.
Tor kan skjule klientens direkte IP for destinationen, men det er ikke en afhjælpning for genbrugte legitimationsoplysninger, identificerende konfigurationsdata eller enhver trafikkorrelationsangreb. Det tilføjer også latenstid. Det nyttige mål er en konsistent administrationssti, hvis adfærd du forstår og kan kontrollere.
Start med en fungerende lokal Tor klient
En system Tor daemon tilbyder almindeligvis SOCKS på 127.0.0.1:9050, mens Tor Browser almindeligvis bruger 9150. Bekræft din faktiske konfiguration i stedet for at antage en af portene. Applikationen skal sende sin forbindelse gennem denne proxy; at åbne Tor Browser ruter ikke ethvert program på computeren.
På understøttede systemer wrapper torsocks applikationer som SSH og ruter understøttede netværkskald gennem Tor. Test opsætningen med en kun-dokumentations-eksempeladresse erstattet af din servers rigtige adresse. Følgende kommando antager en kørende system Tor daemon og en dedikeret administrativ konto.
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]Gør ruten til en del af SSH-konfigurationen
Til almindelig brug reducerer en konfiguration pr. vært risikoen for at glemme en wrapper. Eksemplet nedenfor bruger en netcat-implementering med SOCKS5-proxyunderstøttelse. Implementeringer er forskellige, så bekræft -x- og -X-indstillingerne i din installerede version, og verificér, om værtsnavnsopløsningen er ekstern.
IdentitiesOnly begrænser de nøgler, der tilbydes serveren; kombiner det med en ny nøgle, der bruges til dette projekt. Kontrollér og bevar serverens værtsnøglefingeraftryk via en betroet provisioningkanal. Tor ændrer netværksstien, men SSH værtsautentificering er stadig afgørende.
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 %pFlyt SSH bag en oniontjeneste
Et onionendpoint tillader administration uden en offentligt tilgængelig SSH-port og undgår at bruge en Tor-udgang til denne forbindelse. Installér og konfigurér Tor på serveren, og map derefter en virtuel onionport til den lokale SSH-tjeneste. Eksemplet er en startkonfiguration; tjenestestier og kommandoer varierer efter distribution.
Efter at Tor har oprettet tjenestemappen, skal du hente dens værtsnavnefil privat og teste en forbindelse gennem din klientproxy. Hold oniontjenestens identitetsnøgler private. Først efter et vellykket uafhængigt login bør du begrænse SSH til localhost og fjerne offentlig adgang. Verificér, at din gendannelseskonsol fungerer, før du foretager den ændring.
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22Tilføj klientautorisation til et privat endpoint
Uden ekstra autorisation kan enhver, der lærer onionadressen at kende, nå tjenesten og dens SSH-prompt. Tor v3 klientautorisation tilføjer en separat kryptografisk port: tjenesten har den autoriserede klients offentlige nøgle, og klienten har den matchende private nøgle.
Følg Tor Project's aktuelle instruktioner for nøgleformater og mappen authorized_clients. Verificér, at en uautoriseret klient ikke kan oprette forbindelse. Behold også SSH-nøgleautentificering, og planlæg, hvordan du tilbagekalder autorisationen for en mistet enhed uden at miste din egen resterende adgang.
Test DNS, og undgå identitetslækage
Et værtsnavnsopslag foretaget af den lokale resolver kan afsløre dit mål, før forbindelsen når proxyen. Brug af serverens IP til en clearnet-destination undgår netop dette opslag; onionnavne kræver opløsning inden for Tor. For andre værtsnavne skal du bekræfte programmets eksterne DNS-adfærd i stedet for at stole på en generisk proxyindstilling.
Gæstesystemet kan stadig gemme autentificeringstidsstempler, brugernavne og journalposter. Gennemgå deres opbevaring med vilje i stedet for at deaktivere enhver diagnostik blindt. Undersøg også lokale værtsnavne, commit-metadata og kopieret konfiguration for identificerende detaljer. Tor fjerner ikke disse fra applikationstrafik.
- Brug en dedikeret nøgle og en isoleret projektarbejdsgang.
- Verificér den forventede SOCKS-port og ekstern DNS-adfærd.
- Behold gendannelsesadgang og et andet testet login, før du ændrer lyttere.
- Gennemgå Tor- og SSH-tjenesten efter opdateringer.
- Del aldrig onionidentitetsnøgler eller klientautorisationshemmeligheder.
Hold lange sessioner og fremtidig vedligeholdelse praktisk
Kør lange administrative opgaver i tmux eller screen, så en afbrydelse af forbindelsen ikke ødelægger sessionen. Tor-kredsløb og netværksforhold kan ændre sig, så hold kommandoer gentagelige, og forstå, hvordan de genoptages. En lille smule ekstra latenstid er nemmere at tolerere, når vedligeholdelsen er planlagt.
Det samme onionmønster kan ligge foran et lokalt dashboard eller en privat Git-tjeneste. Hver applikation kræver stadig autentificering, softwareopdateringer og omhyggelig konfiguration. Fortsæt med at bruge den beskyttede rute til support, fornyelse og sikkerhedskopier, hvor dine privatlivskrav kræver det; konsistens betyder lige så meget som den første opsætning.