Comment connecter votre VPS via Tor

Anonymity · 8 min de lecture

Réponse rapide : Vous pouvez router SSH à travers Tor dans deux directions : diriger votre client vers le proxy SOCKS local de Tor pour cacher votre propre IP au serveur, ou publier le port SSH du VPS comme service onion Tor afin que le serveur lui-même n'ait jamais de port SSH accessible sur le clearnet. Les deux peuvent être combinés pour qu'aucune des deux extrémités de la session ne touche jamais l'internet ouvert. Attendez-vous à une latence nettement plus élevée qu'une connexion directe : traitez cela comme une technique d'accès administratif pour du travail interactif en shell, pas comme un transport pour de gros transferts de fichiers.

Deux problèmes différents, tous deux appelés « SSH via Tor »

Les personnes qui recherchent un accès VPS via Tor tentent généralement de résoudre l'un de deux problèmes distincts, et la configuration diffère selon lequel s'applique. Le premier est côté client : vous voulez cacher votre propre adresse IP au serveur, à quiconque surveille votre réseau local, et à quiconque assignera plus tard l'hébergeur VPS à comparaître pour ses journaux de connexion. Le second est côté serveur : vous voulez que le VPS lui-même n'ait aucun port SSH accessible depuis l'internet public, afin qu'il ne puisse être trouvé par un scanner de ports, ciblé par un bot de credential-stuffing, ou géolocalisé via son service à l'écoute.

Ces deux objectifs ne s'excluent pas mutuellement. Une grande partie de la confusion des fils de discussion sur SSH via Tor vient du fait que l'on mélange « je veux cacher qui se connecte » avec « je veux cacher à quoi on se connecte ». Ce guide couvre les deux, en commençant par la configuration côté client, plus simple, puis l'approche par service onion pour le serveur, puis comment durcir le résultat et quelles performances attendre réellement.

Anonymat côté client : votre client SSH transite par Tor, de sorte que le serveur (et quiconque journalise ses connexions entrantes) voit un nœud de sortie ou un relais Tor, pas votre véritable IP
Anonymat côté serveur : sshd n'est accessible que via une adresse onion Tor, il n'existe donc aucune adresse IP:port publique pour SSH

Méthode 1 : router votre client SSH via le proxy SOCKS de Tor

Un client Tor en cours d'exécution (le démon Tor, pas nécessairement Tor Browser) expose un proxy SOCKS5 local, par défaut sur 127.0.0.1:9050. Toute application compatible SOCKS peut y être dirigée, mais SSH lui-même ne parle pas SOCKS nativement, il faut donc un petit pont. Les deux approches courantes sont torsocks, qui encapsule une commande et force ses connexions TCP à passer par le proxy, et une entrée ProxyCommand dans votre configuration SSH qui achemine la connexion via un netcat compatible SOCKS.

Le test le plus rapide consiste simplement à installer tor, confirmer qu'il tourne, puis exécuter torsocks ssh utilisateur@ip-de-votre-vps. Si cela se connecte, votre session SSH passe désormais par un circuit Tor à trois sauts. Pour un usage quotidien, ajoutez plutôt un bloc Host à ~/.ssh/config au lieu de taper torsocks à chaque fois, en utilisant une ligne ProxyCommand telle que nc -X 5 -x 127.0.0.1:9050 %h %p (avec le netcat d'OpenBSD) ou connect -S 127.0.0.1:9050 %h %p (avec l'outil connect-proxy). Ainsi, un simple ssh monhote fonctionne et passe toujours par Tor sans que vous ayez à vous souvenir de l'enveloppe.

Vérifiez que Tor est bien en cours d'exécution et à l'écoute sur le port 9050 avant de dépanner SSH lui-même
torsocks ssh utilisateur@hote est le moyen le plus rapide de tester ; un ProxyCommand dans ~/.ssh/config est le moyen durable de l'utiliser au quotidien
Cette méthode cache votre IP au VPS et à quiconque lit ses journaux d'authentification, mais le port SSH lui-même reste ouvert à l'internet public

Méthode 2 : publier SSH comme service onion Tor sur le VPS

Si l'objectif est de retirer entièrement l'adresse IP propre du VPS de l'équation pour l'accès administratif, le serveur doit faire tourner Tor et n'exposer sshd que comme service caché. Installez tor sur le VPS, puis ajoutez deux lignes à torrc : HiddenServiceDir pointant vers un répertoire dans lequel Tor peut écrire, et HiddenServicePort 22 127.0.0.1:22, qui indique à Tor de transférer les connexions arrivant sur le port 22 de l'adresse onion vers le sshd en écoute localement. Redémarrez Tor, et il génère un nom d'hôte .onion long et aléatoire dans ce répertoire au premier démarrage.

Fait crucial, cette étape ne supprime l'exposition que si sshd est également configuré pour se lier à 127.0.0.1 plutôt qu'à l'interface publique du VPS (ListenAddress 127.0.0.1 dans sshd_config, puis redémarrage de sshd). Sauter cette étape laisse SSH accessible à la fois via l'adresse onion et directement sur l'IP publique, ce qui va à l'encontre du but recherché. Une fois cela fait, connectez-vous depuis le client avec torsocks ssh [email protected] — aucune adresse IPv4 ou IPv6 publique pour SSH n'apparaît plus jamais dans un scan de ports du VPS.

Ajoutez HiddenServiceDir et HiddenServicePort 22 127.0.0.1:22 à torrc, puis redémarrez Tor
Liez sshd lui-même uniquement à 127.0.0.1 — un service onion devant un port encore public ne cache rien
Lisez le fichier hostname généré dans le HiddenServiceDir pour obtenir l'adresse .onion à laquelle vous connecter
Connectez-vous avec torsocks ssh [email protected] ; une IP nue ne fonctionnera plus du tout pour SSH

Verrouiller l'authentification une fois que SSH ne répond plus que sur .onion

Cacher le port ne remplace pas le durcissement de la connexion. Utilisez des paires de clés ed25519, désactivez entièrement l'authentification par mot de passe (PasswordAuthentication no), et désactivez la connexion root via SSH (PermitRootLogin no). Si la clé que vous utilisez pour atteindre ce VPS est la même que celle de vos comptes du quotidien, l'anonymat gagné grâce au service onion est compromis dès que l'empreinte de cette clé apparaît dans une fuite de données ou un scan Shodan/Censys lié à votre nom ailleurs — générez une clé dédiée pour l'infrastructure anonyme.

Une chose cesse discrètement de fonctionner dans cette configuration : les outils basés sur l'IP comme fail2ban. Comme les connexions arrivent à sshd via le processus Tor local, l'adresse source que sshd journalise est 127.0.0.1 pour chaque tentative de connexion, réussie ou non — il n'y a aucune IP d'attaquant à bannir. Ce n'est pas une lacune à combler par un contournement ; l'authentification par clé uniquement, sans repli sur mot de passe, élimine déjà le risque de brute-force que fail2ban est censé atténuer. N'attendez simplement pas que ses journaux soient significatifs dans cette configuration.

Authentification par clé uniquement, ed25519, aucun repli sur mot de passe
Une paire de clés dédiée par serveur anonyme, jamais réutilisée depuis une machine personnelle
PermitRootLogin no, et un compte non-root avec sudo pour le travail réel
Ne comptez pas sur fail2ban ou une liste blanche d'IP une fois le trafic arrivé via Tor — l'IP source dans les journaux est toujours en boucle locale

À quoi ressemblent réellement les performances

Un circuit Tor standard comprend trois relais, et une connexion à un service onion empile deux circuits à trois sauts de bout en bout (un du client vers le réseau Tor, un du réseau Tor vers le service caché), si bien que la latence aller-retour se situe généralement entre quelques centaines de millisecondes et deux secondes, avec des pics occasionnels lors de la reconstruction d'un circuit. Le travail interactif — éditer des fichiers de configuration, consulter des journaux, redémarrer un service — reste parfaitement utilisable à cette latence. Réglez ServerAliveInterval dans votre configuration SSH pour que les sessions inactives ne soient pas coupées à cause du saut supplémentaire, et attendez-vous à un blocage occasionnel pendant que Tor choisit un nouveau circuit.

Ce qui fonctionne moins bien, c'est le débit. scp, rsync, ou tout ce qui déplace des gigaoctets ramperont par rapport à une connexion directe, car les circuits Tor sont optimisés pour l'interactivité à faible latence sur de nombreux flux de courte durée, pas pour une bande passante soutenue. Pour un vrai transfert de données — sauvegardes, gros envois — utilisez un canal chiffré direct (SSH/rsync classique sur l'IP publique, ou un tunnel WireGuard) et réservez le chemin Tor spécifiquement pour l'accès administratif en shell, là où masquer la connexion compte plus que la vitesse.

Les erreurs qui brisent discrètement l'anonymat que vous cherchiez à obtenir

La plupart des échecs ici ne sont pas exotiques — ce sont de petites lacunes de configuration qui laissent une porte dérobée ouverte. Surveillez ceci avant de faire confiance à votre configuration :

Aucune de ces vérifications ne nécessite d'outillage avancé ; il suffit de vérifier une fois les ports réellement à l'écoute et le comportement DNS, plutôt que de supposer que la seule configuration de Tor a fait le travail.

sshd encore lié à l'interface publique en plus du service onion, si bien que le port « caché » est aussi trouvable par un simple scan de ports
Résoudre des noms d'hôte en dehors de Tor (une résolution DNS égarée, ou une application qui ignore le proxy SOCKS pour le DNS) révèle à quel hôte vous êtes sur le point de vous connecter avant même que la connexion Tor ne démarre
Un ProxyCommand qui bascule silencieusement vers une connexion directe si Tor n'est pas en cours d'exécution — configurez-le pour échouer de manière fermée, pas ouverte, afin qu'un démon Tor mort signifie aucune connexion plutôt qu'une connexion accidentelle en clearnet
Réutiliser une clé SSH, une invite de terminal, ou un historique shell qui relie cette session à une identité non anonyme ailleurs

Comparatif des méthodes d'accès SSH
Méthode	Ce qu'elle cache	Latence additionnelle typique	Effort de configuration
SSH direct sur le clearnet	Rien au-delà du chiffrement propre à SSH	Aucune	Aucun
Client routé via le proxy SOCKS de Tor	Votre adresse IP, vis-à-vis du serveur et de ses journaux	Modérée — environ un circuit Tor, ~300 ms à 1 s	Faible — torsocks ou une ligne ProxyCommand
SSH publié comme service onion Tor	L'IP publique du VPS ; aucun port SSH ouvert sur internet	Modérée à élevée — circuit côté serveur ajouté	Moyen — modifications de torrc et sshd_config
Combinaison des deux : client via Tor, serveur en service onion	Les deux extrémités de la connexion restent entièrement hors du clearnet	La plus élevée — deux circuits indépendants à 3 sauts	Moyen

FAQ

SSH via Tor affaiblit-il le chiffrement de SSH ?+

Non. SSH négocie son propre canal chiffré de bout en bout indépendamment du transport qui le porte. Tor ajoute sa propre couche de chiffrement de circuit par-dessus, si bien que le trafic est chiffré deux fois, pas une seule fois avec quelque chose de plus faible.

SSH via Tor est-il trop lent pour de l'administration réelle ?+

Pour les sessions shell interactives — éditer des fichiers, consulter des journaux, redémarrer des services — la latence supplémentaire est perceptible mais gérable. Pour les transferts massifs comme les sauvegardes ou les gros envois, utilisez plutôt une connexion directe ou WireGuard, et réservez le chemin Tor à l'accès administratif.

Puis-je toujours utiliser fail2ban si SSH n'est accessible que via un service onion ?+

Pas de manière utile. Les connexions arrivent à sshd depuis le processus local de Tor, si bien que chaque tentative de connexion est journalisée comme provenant de 127.0.0.1. Reposez-vous plutôt sur l'authentification par clé uniquement, sans repli sur mot de passe, puisque cela élimine le risque de brute-force que fail2ban est censé traiter.

Ai-je besoin d'un VPN en plus de Tor pour accéder à mon VPS ?+

Généralement non. Chaîner un VPN commercial devant Tor déplace surtout la confiance vers le fournisseur VPN sans ajouter de protection réelle pour ce cas d'usage. Tor seul pour la session SSH, ou un tunnel WireGuard quand la latence compte plus que le passage par le réseau Tor, couvrent les cas pratiques.

Les deux extrémités doivent-elles faire tourner Tor, ou seulement mon ordinateur portable ?+

Seul votre client a besoin de faire tourner Tor pour cacher votre propre IP au serveur (Méthode 1). Cacher aussi l'IP du serveur nécessite que le VPS fasse également tourner Tor, avec sshd publié comme service onion (Méthode 2) — les deux configurations sont indépendantes et peuvent être utilisées séparément ou ensemble.

Prêt à passer offshore ?

Aucun KYC, aucun e-mail — juste une clé anonyme et de la crypto. Déployez en ~55 secondes.

Configurer votre VPS →