Administrer votre VPS avec Tor
Configurez SSH via SOCKS, créez un accès onion privé et vérifiez DNS, authentification et récupération avant de fermer l'accès public.
L’essentiel
Tor peut modifier le parcours réseau vers un VPS ; un accès SSH onion évite une destination d’administration publique classique. Aucune approche ne sécurise automatiquement le serveur. Protège les clés SSH, vérifie l’identité de l’hôte, limite les accès et teste la configuration avant de lui faire confiance.
Protéger l'administration autant que la commande
Commander un serveur dans un navigateur protégé ne protège pas automatiquement une connexion SSH ultérieure. Une connexion directe peut révéler votre adresse au serveur et aux réseaux traversés. Définissez le parcours d'administration avant la première session, y compris l'accès de secours si le chemin préféré tombe en panne.
Tor peut masquer l'IP directe du client à la destination, mais ne corrige ni des identifiants réutilisés, ni une configuration identifiante, ni toutes les analyses de corrélation du trafic. Il ajoute également de la latence. L'objectif utile est un chemin cohérent dont vous comprenez et vérifiez le fonctionnement.
Commencer avec un client Tor local fonctionnel
Un démon système Tor propose couramment SOCKS sur 127.0.0.1:9050, tandis que Tor Browser utilise couramment 9150. Vérifiez votre configuration réelle au lieu de présumer l'un ou l'autre port. L'application doit envoyer sa connexion via ce proxy ; l'ouverture de Tor Browser ne route pas tous les programmes de l'ordinateur.
Sur les systèmes compatibles, torsocks enveloppe des applications comme SSH et fait passer leurs appels réseau pris en charge par Tor. Testez la configuration en remplaçant l'adresse de documentation par celle de votre serveur. La commande suivante suppose un service Tor système actif et un compte d'administration dédié.
torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]Inscrire le parcours dans la configuration SSH
Pour un usage régulier, une configuration par hôte réduit le risque d'oublier le programme intermédiaire. Cet exemple utilise une version de netcat avec prise en charge du proxy SOCKS5. Les versions diffèrent : vérifiez les options -x et -X de votre installation, ainsi que la résolution distante des noms.
IdentitiesOnly limite les clés présentées au serveur ; utilisez une clé nouvelle pour ce projet. Contrôlez et conservez l'empreinte de la clé d'hôte par un canal de provisionnement fiable. Tor change le chemin réseau, mais l'authentification de l'hôte SSH reste indispensable.
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 %pPlacer SSH derrière un service onion
Un point de terminaison onion permet l'administration sans port SSH accessible publiquement et évite d'utiliser une sortie Tor pour cette connexion. Installez et configurez Tor sur le serveur, puis mappez un port virtuel onion vers le service SSH local. L'exemple est une configuration de départ ; les chemins de service et les commandes varient selon la distribution.
Après que Tor a créé le répertoire de service, récupérez son fichier hostname en privé et testez une connexion via votre proxy client. Gardez les clés d'identité du service onion privées. Ce n'est qu'après une connexion indépendante réussie que vous devez restreindre SSH à localhost et supprimer l'accès public. Vérifiez que votre console de récupération fonctionne avant d'effectuer ce changement.
HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22Ajouter l'autorisation des clients
Sans autorisation supplémentaire, toute personne qui obtient l'adresse onion peut atteindre le service et sa demande de connexion SSH. L'autorisation des clients Tor v3 ajoute une barrière cryptographique : le service possède la clé publique du client autorisé, et ce client conserve la clé privée correspondante.
Suivez la documentation actuelle du Tor Project pour les formats de clés et le répertoire authorized_clients. Vérifiez qu'un client non autorisé ne se connecte pas. Conservez aussi l'authentification SSH par clé, et prévoyez la révocation d'un appareil perdu sans supprimer vos derniers accès.
Tester le DNS et limiter les données identifiantes
Une résolution par le DNS local peut révéler la destination avant que la connexion atteigne le proxy. Utiliser l'IP pour une destination classique évite cette résolution ; les noms onion demandent une résolution dans Tor. Pour les autres noms, vérifiez le comportement DNS distant de l'application au lieu de vous fier à une option générale.
Le système invité peut encore garder des horaires d'authentification, pseudonymes et événements système. Choisissez leurs durées de conservation sans désactiver aveuglément tous les diagnostics. Examinez aussi les noms de machines, métadonnées de commits et configurations copiées. Tor ne retire pas ces informations des échanges applicatifs.
- Utilisez une clé dédiée et un environnement isolé pour le projet.
- Vérifiez le port SOCKS et la résolution DNS distante.
- Gardez un accès de secours et une seconde connexion testée avant de modifier les écoutes.
- Contrôlez Tor et SSH après les mises à jour.
- Ne partagez jamais les clés d'identité onion ni les secrets d'autorisation.
Rendre les longues sessions et la maintenance pratiques
Lancez les longues tâches dans tmux ou screen pour qu'une coupure ne détruise pas votre session. Les circuits Tor et les conditions réseau peuvent évoluer : rendez les commandes reproductibles et sachez les reprendre. La latence se gère mieux lorsque la maintenance est préparée.
Le même modèle onion peut donner accès à un tableau de bord local ou un service Git privé. Chaque application demande toujours une authentification, des mises à jour et une configuration soignée. Appliquez aussi le parcours protégé au support, aux renouvellements et aux sauvegardes lorsque vos besoins le demandent.