Browse Source

Ajout d'une section cocnernant le keepalive ssh sur l'article ssh overs ssl

master
LecygneNoir 2 months ago
parent
commit
1813af8ec9
1 changed files with 12 additions and 4 deletions
  1. +12
    -4
      content/2024/ssh_over_haproxy.rst

+ 12
- 4
content/2024/ssh_over_haproxy.rst View File

@ -45,7 +45,7 @@ PS: Dans le cas où le filtrage se ferait avec un système de `Deep Packet Inspe
La première étape va consister à assez simplement faire passer votre flux SSH sur le port 443. Si vous rencontrez un simple pare-feu qui bloque tous les ports sauf le 443, cela permettra de contourner le blocage sans problème.
Côté serveur on pourrait simplement faire écouter sshd sur ce port, ou utiliser iptables pour NATer le port 443 vers le port 22 de votre serveur **mais** c'est moins fun, et puis si vous avez déjà des sites web votre port 443 est déjà utilisé.
Côté serveur on pourrait simplement faire écouter sshd sur ce port, ou utiliser iptables pour NATer le port 443 vers le port 22 de votre serveur **mais** c'est moins fun, et puis si vous avez des sites web votre port 443 est déjà utilisé.
C'est là qu'Haproxy va intervenir car il est capable de détecter si le flux entrant est du SSH ou de l'http !
Cette étape est assez simple, on va demander à Haproxy de rediriger le flux http (plus précisément, ssl) vers votre frontend habituel, et le flux ssh **vers un serveur particulier**. On verra ensuite une technique pour dire à Haproxy quel serveur ssh on souhaite joindre 😄
@ -98,7 +98,7 @@ Ici on définit **deux ACLs** :
* L'acl ``trafic_ssl`` se base simplement sur le fait que le flux est chiffré avec ssl
* l'acl ``trafic_ssh_raw`` quand à elle, vérifie les 7 premiers bits de payload de la connexion TCP, qui contiennent ``SSH-2.0`` dans le cas d'une transaction SSH !
Sur la base de ces ACL, on peut facilement rediriger vers les backends qui vont bien
Sur la base de ces ACL, on peut facilement rediriger vers les backends qui vont bien
.. code-block:: bash
@ -279,8 +279,6 @@ On va également enrichir notre backend ``bk_sshssl``
Modifiez comme bon vous semble ``RESEAU/24`` ou ``IP/32`` pour indiquer les réseaux ou serveurs autorisés à être joint par ces connexion SSH. Il vous suffit de les séparer par des espaces.
Et voila, votre proxy SSH overs SSL est fin prêt à affronter les pare-feu que vous voudriez bien lui fournir !
Et comment qu'on s'y connecte ?
-------------------------------
@ -298,6 +296,16 @@ Avec :
* ``-l USER`` : L'utilisateur ssh à utiliser
* ``dummy.name``: Contrairement à une connexion ssh classique, ce nom ne sera jamais ni résolu ni utilisé pour joindre le serveur ssh. **Néanmoins** c'est sous ce nom que l'empreinte SSH du serveur sera enregistrée dans votre fichier known_hosts, donc je vous conseille de le changer pour un nom pertinent en rapport avec ``IP_A_SSH``
Au passage **petit conseil d'expérience**, par défaut haproxy traite les flux dans un contexte "question/réponse", puisqu'après tout http fonctionne rarement en flux contenu, contrairement à SSH.
Du coup, ça génère des déconnexions de vos sessions SSH si elle ne font rien pendant quelques minutes/secondes, ce qui est un peu chiant.
Je vous invite à ajouter **côté client ssh** une configuration keepalive pour que votre client se charge d'envoyer des ping dans le tunnel et ainsi maintenair la connexion :
.. code-block:: bash
$ cat ~/.ssh/config
Host *
ServerAliveInterval 10
Au final
========

Loading…
Cancel
Save