En Tor-baserad hanteringsväg för din VPS
Använd en SOCKS-proxy för SSH, publicera en privat onion-slutpunkt och kontrollera DNS, autentisering och återställning innan du stänger offentlig åtkomst.
I korthet
Tor kan ändra nätverksvägen som används för att nå en VPS, och en onion-slutpunkt i SSH kan undvika ett konventionellt offentligt administrationsmål. Ingen av metoderna säkrar servern automatiskt. Skydda SSH-nycklar, verifiera värdens identitet, begränsa åtkomsten och testa konfigurationen innan du förlitar dig på den.
Skydda administration såväl som kassa
Att beställa en server via en skyddad webbläsare skyddar inte automatiskt en senare SSH-session. En direkt inloggning kan avslöja din källadress för servern och nätverken längs vägen. Bestäm hur administrationen ska fungera före den första anslutningen, inklusive nödåtkomst om den föredragna vägen misslyckas.
Tor kan dölja klientens direkta IP för destinationen, men det är inte ett botemedel mot återanvända autentiseringsuppgifter, identifierande konfigurationsdata eller varje trafikkorrelationsattack. Det tillför också latens. Det användbara målet är en konsekvent hanteringsväg vars beteende du förstår och kan kontrollera.
Börja med en fungerande lokal Tor-klient
En systemdaemon för Tor erbjuder vanligtvis SOCKS på 127.0.0.1:9050, medan Tor Browser vanligtvis använder 9150. Verifiera din faktiska konfiguration istället för att anta endera porten. Applikationen måste skicka sin anslutning genom den proxyn; att öppna Tor Browser dirigerar inte varje program på datorn.
På system som stöds omsluter torsocks applikationer som SSH och dirigerar nätverksanrop som stöds genom Tor. Testa inställningen med en dokumentationsadress som endast är ett exempel, ersatt med din servers riktiga adress. Följande kommando förutsätter en körande systemdaemon för Tor och ett dedikerat administrativt konto.
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]Gör rutten till en del av konfigurationen för SSH
För vanlig användning minskar en konfiguration per värd risken att glömma en wrapper. Exemplet nedan använder en netcat-implementering med SOCKS5-proxy-stöd. Implementeringar skiljer sig, så bekräfta alternativen -x och -X i din installerade version och verifiera om värdnamnsuppslagningen sker på distans.
IdentitiesOnly begränsar vilka nycklar som erbjuds till servern; kombinera det med en ny nyckel som används för detta projekt. Kontrollera och behåll serverns värdnyckelfingeravtryck via en betrodd provisioning-kanal. Tor ändrar nätverksvägen, men värdautentisering för SSH är fortfarande viktig.
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 %pFlytta SSH bakom en onion-tjänst
En onion-slutpunkt möjliggör administration utan en offentligt nåbar SSH-port och undviker att använda en Tor-utgång för denna anslutning. Installera och konfigurera Tor på servern och mappa sedan en virtuell onion-port till den lokala SSH-tjänsten. Exemplet är en startkonfiguration; tjänstevägar och kommandon varierar mellan distributioner.
När Tor har skapat tjänstekatalogen hämtar du dess värdnamnsfil privat och testar en anslutning genom din klientproxy. Håll onion-tjänstens identitetsnycklar privata. Först efter en lyckad oberoende inloggning bör du begränsa SSH till localhost och ta bort offentlig åtkomst. Verifiera att din återställningskonsol fungerar innan du gör den ändringen.
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22Lägg till klientauktorisering för en privat slutpunkt
Utan extra auktorisering kan vem som helst som får kännedom om onion-adressen nå tjänsten och dess SSH-prompt. Klientauktorisering för Tor v3 lägger till en separat kryptografisk grind: tjänsten har den auktoriserade klientens publika nyckel och klienten har den matchande privata nyckeln.
Följ Tor-projektets aktuella instruktioner för nyckelformat och katalogen authorized_clients. Verifiera att en obehörig klient inte kan ansluta. Behåll även nyckelautentisering för SSH och planera hur du återkallar auktoriseringen för en förlorad enhet utan att förlora din egen återstående åtkomst.
Testa DNS och undvik identitetsläckage
En värdnamnssökning som görs av den lokala resolveraren kan avslöja ditt mål innan anslutningen når proxyn. Att använda serverns IP för ett clearnet-mål undviker just den sökningen; onion-namn kräver uppslagning inom Tor. För andra värdnamn, bekräfta programmets beteende för fjärransluten DNS i stället för att förlita dig på en generisk proxyinställning.
Gästsystemet kan fortfarande behålla autentiseringstidsstämplar, användarnamn och journalposter. Granska deras bevarande avsiktligt i stället för att blint inaktivera all diagnostik. Inspektera även lokala värdnamn, commit-metadata och kopierad konfiguration för identifierande detaljer. Tor tar inte bort dessa från applikationstrafik.
- Använd en dedikerad nyckel och ett isolerat projektarbetsflöde.
- Verifiera den förväntade SOCKS-porten och fjärrbeteendet för DNS.
- Behåll återställningsåtkomst och en andra testad inloggning innan du ändrar lyssnare.
- Granska tjänsterna Tor och SSH efter uppdateringar.
- Dela aldrig onion-identitetsnycklar eller hemligheter för klientauktorisering.
Håll långa sessioner och framtida underhåll praktiska
Kör långa administrativa jobb i tmux eller screen så att ett avbrott i anslutningen inte förstör sessionen. Tor-kretsar och nätverksförhållanden kan förändras, så håll kommandon repeterbara och förstå hur du återupptar dem. En liten extra latens är lättare att tolerera när underhållet är planerat.
Samma onion-mönster kan ligga framför en lokal instrumentpanel eller en privat Git-tjänst. Varje applikation behöver fortfarande autentisering, programuppdateringar och noggrann konfiguration. Fortsätt använda den skyddade rutten för support, förnyelse och säkerhetskopior där dina integritetskrav kräver det; konsekvens spelar lika stor roll som den initiala installationen.