Par l'équipe HushVPS · Mis à jour en 2026 · 8 min de lecture
Vous avez acheté un serveur anonyme, payé en Monero, et sauté la vérification d'identité. Puis vous vous connectez en SSH depuis votre IP personnelle sur l'internet ouvert — et vous remettez tranquillement à votre FAI, au réseau de transit, et à quiconque observe la machine, une ligne claire reliant votre visage à la machine. Si vous voulez gérer un serveur via Tor, l'objectif est simple : ne laissez jamais un paquet clearnet connecter votre emplacement réel à la machine que vous administrez. Ce guide couvre les méthodes pratiques pour atteindre et exécuter un VPS entièrement via le réseau Tor, et les fuites qui le compromettent silencieusement.
Tor vous offre deux primitives utiles pour l'administration. Vous pouvez router votre SSH sortant à travers Tor en tant que client, afin que votre IP réelle ne touche jamais le serveur. Ou vous pouvez publier le démon SSH lui-même comme service onion, de sorte que la machine n'ait aucun port de gestion exposé sur le clearnet. La plupart des opérateurs prudents finissent par utiliser les deux ensemble. Nous construirons à partir de la configuration la plus simple jusqu'à la plus robuste.
La mise à disposition anonyme ne couvre que la porte d'entrée. Si vous vous inscrivez sans KYC et payez avec un VPS sans KYC facturé en Monero, le fournisseur n'a ni nom ni carte liés à votre compte — mais dès que vous vous connectez depuis votre connexion personnelle, vous créez une nouvelle piste papier continue. Votre FAI voit des connexions répétées vers une IP de datacenter spécifique. Les journaux d'authentification du serveur enregistrent l'adresse source de chaque session. Corrélez les deux et l'anonymat que vous avez payé s'évapore.
Router le trafic de gestion via Tor comble cette lacune. Votre FAI voit seulement que vous avez utilisé Tor ; il ne peut pas voir quel serveur vous avez atteint. Le VPS voit une sortie Tor (ou un point de rendez-vous, pour SSH onion), jamais votre adresse. L'identité que vous avez gardée hors du formulaire d'inscription reste hors du fil, session après session.
Tor protège le chemin réseau. Il n'assainit pas la machine, le compte, ni vos habitudes opérationnelles. Avant de commencer, soyez clair sur ce contre quoi vous vous défendez réellement : un observateur passif sur votre réseau local, la capacité du fournisseur à corréler votre IP de gestion avec la machine, et les journaux qui survivent à la session. Tor répond à ces trois points. Il ne protège pas si vous collez votre vrai nom d'hôte dans une configuration, réutilisez une clé SSH déjà liée à votre nom ailleurs, ou exécutez un outil qui fuit en résolvant le DNS hors du tunnel. Gardez le modèle honnête et vous ferez les bons compromis ci-dessous.
Le moyen le plus rapide de tunneler une seule commande via Tor est torsocks, un wrapper qui force les appels réseau d'un programme à travers le proxy SOCKS local de Tor (généralement 127.0.0.1:9050). Installez le client Tor sur votre poste de travail, assurez-vous que le démon tourne, puis préfixez votre commande SSH :
torsocks ssh [email protected]Le détail crucial est le DNS. Un ssh hostname naïf résout le nom sur votre machine d'abord, via votre résolveur habituel — une fuite classique qui indique à votre FAI exactement quel hébergeur vous allez joindre, avant même que Tor ne voie la connexion. torsocks intercepte getaddrinfo et fait passer la résolution par Tor également, de sorte que la requête n'atteint jamais votre résolveur local. Se connecter à une IP brute évite entièrement la résolution de nom et est l'habitude la plus sûre. Dans tous les cas, vérifiez : si vous voyez une requête DNS pour le nom d'hôte de votre serveur sur votre propre réseau, le tunnel ne fait pas son travail.
Pour tout ce que vous faites plus d'une fois, intégrez Tor dans ~/.ssh/config afin de ne pas oublier l'enveloppe. En utilisant netcat avec un proxy SOCKS, un bloc par hôte ressemble à ceci :
Host ghost
HostName 203.0.113.10
User admin
ProxyCommand nc -x 127.0.0.1:9050 -X 5 %h %p
IdentitiesOnly yes
IdentityFile ~/.ssh/ghost_ed25519Maintenant, ssh ghost se connecte toujours via le port SOCKS5 de Tor, et %h/%p sont remis au proxy — de sorte que la résolution de nom se fait à la sortie, pas sur votre machine. Définissez IdentitiesOnly yes pour que votre client ne déploie pas toutes les clés de votre agent vers le serveur (ce qui est à la fois une empreinte et une petite fuite). Donnez à chaque machine anonyme sa propre clé dédiée qui n'est associée à votre identité réelle nulle part ailleurs, et désactivez l'authentification par mot de passe côté serveur afin qu'une identifiante devinée soit sans valeur.
Une bizarrerie à connaître : Tor ajoute de la latence et chaque nouveau circuit est une sortie fraîche et aléatoire, donc la saisie interactive peut sembler lente et les sessions de longue durée peuvent parfois tomber lorsqu'un circuit tourne. Exécuter votre travail dans tmux ou screen sur le serveur signifie qu'un circuit interrompu vous coûte une reconnexion, pas votre session.
La posture la plus robuste supprime entièrement le port de gestion clearnet. Au lieu d'exposer le port 22 à l'internet et de le protéger par un pare-feu, vous exécutez un service onion Tor sur le VPS qui redirige vers 127.0.0.1:22. Le démon SSH ne se lie alors qu'à localhost ; rien ne répond sur l'IP publique. Vous l'atteignez à une adresse .onion, via Tor, de bout en bout.
Sur le serveur, ajoutez un service onion à votre torrc pointant vers le port SSH local :
HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22Redémarrez Tor, lisez le fichier hostname généré pour votre .onion v3, et connectez-vous depuis un client qui route via Tor :
torsocks ssh [email protected]Cela présente deux grands avantages. Premièrement, il n'y a pas de port SSH exposé que l'internet puisse scanner, attaquer par force brute ou prendre l'empreinte — les attaques automatisées contre le port 22 n'ont simplement rien à viser. Deuxièmement, l'emplacement de la machine est caché au client et l'emplacement du client est caché à la machine ; le rendez-vous se fait à l'intérieur de Tor. Suivez la configuration actuelle et faisant autorité de la documentation du service onion du projet Tor plutôt qu'un vieux blog, car les directives torrc exactes et les formats de clé changent entre les versions. Pour un panneau d'administration, un tableau de bord privé ou un dépôt Git, le même modèle s'applique — publiez le port localhost comme onion et atteignez-le via Tor. Notre tutoriel sur l'exécution d'un service caché Tor sur un VPS anonyme approfondit cet aspect.
Une adresse onion simple est impossible à deviner mais pas vraiment privée — quiconque apprend le .onion peut atteindre l'invite de connexion. Tor prend en charge l'autorisation client, où l'oignon ne complète même pas une poignée de main à moins que le client connecté ne présente une clé pré-partagée. Ajoutez la clé publique de votre client au répertoire authorized_clients du service et l'oignon devient invisible pour tous les autres : pas de clé, pas de connexion, pas d'invite. Pour un point de gestion que vous seul touchez, cela transforme la « sécurité par une adresse impossible à deviner » en une véritable porte cryptographique.
La façon la plus courante de fuir en pensant être anonyme est le DNS. Si une partie de votre flux de travail résout le nom du serveur en dehors de Tor, vous avez annoncé votre cible. Préférez vous connecter par IP ou .onion ; lorsque vous devez utiliser un nom d'hôte, assurez-vous que la résolution est proxifiée (torsocks, un ProxyCommand, ou un paramètre SOCKS au niveau de l'application avec DNS distant activé). L'explication de l'EFF sur ce que Tor cache et ne cache pas est un bon rappel à la réalité sur où la protection s'arrête.
Quelques pièges supplémentaires à nommer :
L'anonymat n'est pas une configuration ponctuelle ; c'est une discipline que vous maintenez session après session. La chaîne ne tient que si chaque maillon tient : inscription anonyme sans KYC, paiement en Monero pour qu'il n'y ait pas de registre de carte, une clé SSH dédiée qui n'est pas liée à votre nom, un DNS qui ne s'échappe jamais du tunnel, et une administration exclusivement via Tor ou un onion authentifié. Si vous rompez un seul maillon, les autres ne peuvent pas vous sauver. Gardez-les tous et il n'y a tout simplement aucun point dans le pipeline où votre identité réelle et votre serveur se rencontrent.
Accès root complet, sans KYC, facturation en Monero, sans logs par défaut. Apportez votre propre clé, publiez un service onion, et administrez-le sans que votre identité ne touche jamais au réseau.
HushVPS est légal offshore et minimise les données, ce n'est pas une zone de non-droit. Gérer votre propre machine via Tor est une pratique de confidentialité normale ; notre politique d'utilisation acceptable interdit toujours les CSAM, les logiciels malveillants et l'infrastructure de botnet, le spam et les DDoS.