Redirection SSH locale ou VPN complet pour un écran de Mac ?
Pour un écran sur un seul hôte, une redirection SSH en loopback est plus petite qu’un VPN. Voici quand elle suffit, ce qu’elle chiffre et quand arrêter de l’utiliser.
Vous devez voir l’écran d’un Mac depuis votre propre machine, le Mac se trouve derrière un hôte auquel vous pouvez déjà vous connecter en SSH, et la question est de savoir si cela mérite un VPN. En général, non. Une seule redirection locale transporte un port TCP à travers la session SSH que vous avez déjà, et pour un écran sur un seul hôte, c’est un dispositif plus petit et plus auditable que le routage de tout un réseau.
Trois conditions le décident, et l’une ou l’autre peut vous pousser vers le VPN géré.
Trois conditions le décident
La première est la portée : un service sur un seul hôte, ou plusieurs hôtes et plusieurs ports. La deuxième est de savoir si chaque saut entre le bastion et la cible est déjà de confiance, car SSH ne protège que le segment qu’il termine. La troisième est qui devra maintenir le dispositif après que vous l’aurez construit, car un tunnel bricolé tend à survivre à la personne qui l’a compris. Nommez cette personne avant de commencer, et écrivez la commande à un endroit où elle pourra la trouver. Une redirection non documentée est un incident futur à date de début différée.
Si les réponses sont « un », « oui » et « moi, pour l’instant », la redirection est le bon outil. Si une réponse change, une conception d’accès distant prise en charge coûte moins cher sur un an que la revue d’incident qui suit un tunnel non documenté.
Redirigez un port, pas le réseau
Une redirection locale ouvre un écouteur sur votre machine et relaie chaque connexion à travers le serveur SSH vers une destination que ce serveur peut atteindre. Pour un Mac dont le service de partage d’écran écoute sur TCP 5900, et un bastion qui peut résoudre mac.corp.example, la commande est courte et volontairement étroite. Chaque option qu’elle contient existe pour garder le dispositif petit : pas de shell, pas d’écouteur sur toutes les interfaces, pas de démon. Lisez-la comme une déclaration de portée, pas comme une recette.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]Lier l’écouteur à 127.0.0.1 le tient à l’écart de toute autre interface. Ce n’est pas une formalité : une redirection liée à toutes les interfaces transforme votre portable en relais ouvert vers le réseau d’entreprise pour quiconque sur le même Wi-Fi de café. Si le port est déjà utilisé, choisissez un autre port haut et mettez à jour la visionneuse ; n’arrêtez pas un service sans rapport pour faire cadrer l’exemple.
Le compte sur le bastion a aussi besoin de l’autorisation de rediriger vers cette destination. Certaines configurations SSH durcies désactivent complètement la redirection de ports, et d’autres la restreignent avec une directive permit-listen ou permit-open. Lisez la politique du serveur avant de supposer qu’un canal refusé signifie que le mot de passe était faux.
Ce que SSH chiffre, et où cela s’arrête
La session SSH protège le trafic de votre Mac vers le bastion, et la redirection transporte le protocole VNC à l’intérieur de cette session sans le comprendre. Une fois la connexion sortie du bastion vers la cible, elle n’est plus dans votre session SSH. Quelle que soit la protection présente sur ce dernier saut, elle appartient au protocole de la cible et aux contrôles propres du réseau privé.
C’est pourquoi un dernier saut VNC simple ne doit pas être décrit comme chiffré de bout en bout simplement parce que le premier saut a utilisé SSH. Décrivez les segments honnêtement : fort du client au bastion, puis ce que la cible prend en charge. Si l’exigence est que tout le chemin soit chiffré par un seul mécanisme, la redirection ne la remplit pas.
L’authentification sur la cible est encore une autre affaire. Le compte SSH n’accorde pas une connexion macOS, et le service de partage d’écran demande toujours ses propres identifiants et applique toujours sa propre liste d’accès. Un écouteur local qui accepte une connexion ne prouve rien sur la question de savoir si le service distant admettra la session.
Quand le VPN complet est le bon choix
Choisissez le VPN lorsque la tâche exige plus d’un port : les fonctions de gestion et de rapport d’Apple Remote Desktop utilisent du trafic TCP et UDP supplémentaire qu’une seule redirection TCP ne portera pas. Une redirection n’est pas une implémentation partielle du produit entier ; c’est un outil différent, plus petit.
Choisissez-le lorsque plusieurs administrateurs se connectent depuis des lieux changeants, car un profil géré distribue routes, identifiants et politique sans que chaque personne invente une ligne de commande. Choisissez-le lorsque la piste d’audit doit montrer qui s’est connecté à quoi, car une session SSH par utilisateur et une redirection locale partagée laissent des enregistrements très différents.
Choisissez-le, enfin, lorsque le réseau cible ne doit pas être joignable depuis un portable sans la porte propre de l’organisation. Une redirection personnelle contourne cette porte par conception, et c’est exactement pourquoi elle relève d’un registre des changements et non d’un historique de shell.
Faites échouer la redirection bruyamment
Utilisez ExitOnForwardFailure=yes pour qu’une liaison échouée arrête la session au lieu de laisser un shell qui semble connecté et ne redirige rien. Gardez la vérification de clé d’hôte activée, et préférez une clé ou un agent à un mot de passe. Testez ensuite l’URL exacte que la visionneuse utilisera, car une session SSH fonctionnelle et une connexion d’écran fonctionnelle sont deux résultats différents.
Pour le client natif sous macOS, la visionneuse est atteinte via une URL locale : open "vnc://127.0.0.1:15900". Si la fenêtre s’ouvre et que l’hôte distant refuse l’authentification, le tunnel est correct et le problème vient de la cible. Si la fenêtre ne s’ouvre jamais, le problème vient de l’écouteur ou du port.
Arrêtez la session quand vous avez terminé, et notez le port, le bastion, la cible et la politique du compte. Une redirection que personne n’a documentée est indiscernable d’une porte dérobée six mois plus tard, et c’est l’argument le plus fort pour la garder petite, nommée et temporaire.