Guide visuel du tunneling SSH et de la redirection de ports (2023)

 (ittavern.com)
6 points par GN⁺ 2024-09-20 | 1 commentaires | Partager sur WhatsApp

Guide visuel du tunneling SSH et de la redirection de ports

  • Résumé : ce billet de blog a été rédigé pour aider à comprendre le tunneling SSH et la redirection de ports. Il couvre les cas d’usage, la configuration, les jump hosts SSH, la redirection de ports locale/distante/dynamique, ainsi que les limitations.
Cas d’usage

  • Sécurité :

    • Chiffrer des connexions non sécurisées comme FTP
    • Accéder à un panneau d’administration web via un tunnel SSH (authentification par clé publique)
    • Réduire le nombre de ports exposés (seul le port 22 est exposé)

  • Dépannage :

    • Contourner les pare-feu / filtres de contenu
    • Choisir un autre chemin

  • Connectivité :

    • Accéder à des serveurs derrière un NAT
    • Utiliser un jump host pour accéder à des serveurs internes via Internet
    • Exposer un port local sur Internet
Redirection de ports
  • Configuration / préparation :
    • Les utilisateurs locaux et distants doivent avoir l’autorisation d’ouvrir des ports
    • Les ports 0 à 1024 nécessitent les privilèges root
    • Configurer correctement les pare-feu du client et du réseau
    • La redirection de ports doit être activée sur le serveur SSH : AllowTcpForwarding yes
    • Pour rediriger des ports sur d’autres interfaces, il faut activer GatewayPorts yes
Jump host SSH / tunnel SSH

  • Connexion via un jump host :

    ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1

  • Utilisation de plusieurs jump hosts :

    ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
Redirection de port locale

  • Exemple 1 :

    ssh -L 10.10.10.1:8001:localhost:8000 user@REMOTE-MACHINE

  • Exemple 2 :

    ssh -L 8001:10.99.99.1:8000 user@REMOTE-MACHINE
Redirection de port distante

  • Exemples 1+2 :

    ssh -R 8000:localhost:8001 user@REMOTE-MACHINE
ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE

  • Exemple 3 :

    ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE
Redirection de port dynamique
  • Utilisation du protocole SOCKS : 
    ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
Tunneling SSH TUN/TAP
  • Créer un tunnel TCP bidirectionnel : 
    ssh -w local_tun[:remote_tun]
Exécuter SSH en arrière-plan

  • Exécution en arrière-plan :

    ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE

  • Arrêter SSH en arrière-plan :

    ps -ef | grep ssh
kill <PID>
Maintenir la connexion SSH
  • Gestion du timeout :
    • ClientAliveInterval 15
    • ClientAliveCountMax 3
Limitations

  • UDP :

    • SSH nécessite une transmission fiable, donc UDP n’est pas pris en charge

  • TCP-over-TCP :

    • L’augmentation de l’overhead réduit le débit et augmente la latence

  • Pas un remplacement de VPN :

    • Le tunneling SSH peut remplacer un VPN, mais du point de vue des performances, un VPN est plus adapté

  • Risques de sécurité potentiels :

    • Il est recommandé de désactiver les fonctionnalités non nécessaires

Résumé de GN⁺

  • Cet article explique les différents cas d’usage du tunneling SSH et de la redirection de ports, ainsi que leurs méthodes de configuration
  • Le tunneling SSH est utile pour fournir des connexions sécurisées et contourner les pare-feu
  • Il ne remplace toutefois pas un VPN et présente des limitations comme une baisse de performances
  • Parmi les autres projets liés, on trouve des solutions VPN comme OpenVPN

À lire aussi

1 commentaires

 
GN⁺ 2024-09-20
Avis Hacker News

  • En 2024, il vaut mieux utiliser le fichier ~/.ssh/config pour configurer LocalForward, RemoteForward et ProxyJump plutôt que d’écrire directement les commandes SSH

    • Une configuration d’exemple permet de gagner du temps lorsqu’on transfère des données en passant par plusieurs connexions SSH intermédiaires
    • Après configuration, il est possible d’utiliser SSH, SCP et rsync vers target-server via un alias
    • Les réglages LocalForward et RemoteForward permettent de faire du port forwarding facilement

  • Le tunneling SSH est indispensable dans des environnements d’entreprise complexes

    • À cause de nombreuses lourdeurs administratives et de temps d’attente, obtenir les droits d’accès nécessaires prend du temps
    • En utilisant la commande ssh -D 8888 someserver et en configurant le proxy SOCKS du navigateur sur localhost:8888, le trafic du navigateur est routé via ce serveur

  • Si l’on veut se connecter en SSH à un serveur Linux ou à un appareil IoT situé derrière un pare-feu et sans IP fixe, on peut utiliser un service de tunneling

  • L’expérience de bidouillage SSH la plus complexe s’est produite lors d’une connexion entre centres de données

    • Il fallait déplacer des données de A vers B, puis de B vers C
    • En combinant rsync, des tunnels SSH, des clés et du routage, les données ont pu être déplacées avec succès
    • À l’époque, c’était une grande réussite, et ce souvenir reste encore très vif

  • On aimerait voir davantage de visualisations réseau

    • En particulier, une visualisation du trafic au niveau des connexions bas niveau serait utile

  • Le TCP-over-TCP peut augmenter l’overhead et la latence, ce qui peut dégrader les performances

    • Dans les tunnels SSH, ce n’est pas un problème sauf si l’on utilise TAP/TUN
    • En revanche, une dégradation des performances peut apparaître lorsqu’on utilise plusieurs canaux

  • Les tunnels SSH sont un excellent outil, mais aujourd’hui on utilise davantage des outils intégrant TLS et des fonctions de reverse proxy

  • sshuttle est un meilleur outil pour le tunneling

    • On peut l’utiliser comme un VPN avec la commande sshuttle -r user@host 10.0.0.0/8

  • Il y a 15 ans, quelqu’un a commencé à utiliser des tunnels SSH pour contourner le pare-feu du réseau universitaire

    • Le port par défaut avait été remplacé par 443
    • Depuis, il est utilisé pour bien d’autres usages que le simple contournement de pare-feu

  • On se demande si SSH lui-même dispose d’une fonction de redirection

    • Si A tente une connexion SSH vers B, B pourrait indiquer de se connecter à C, et A se connecterait alors directement à C de manière transparente
    • B ne ferait alors plus partie du chemin critique des données
    • On se demande si une telle fonctionnalité existe déjà