Il y a des choses dont on est vraiment certain. Par exemple, le fait qu’un seul processus puisse, à un instant T, être en écoute sur un couple IP/Port donné. C’est ainsi que fonctionne tous les systèmes d’exploitations et les connexions réseaux depuis la nuit des temps. (Je parle bien sur de l’age reculé de l’invention de TCP/IP).
Aussi, en voyant une personne demander comment faire pour qu’apache et sshd écoutent simultanément dernière le port 443 de la même machine (et bien évidement sur la même interface), je n’ai même pas pris la peine de répondre. Je me suis juste dit qu’elle n’avais pas tout compris au fonctionnement du base du réseau.
Alors quand, une heure plus tard, cette même personne est revenue répondre à sa propre question avec une technique parfaitement fonctionnelle, j’avoue que ça m’a mis un petit coup au moral 🙂 Certes, je n’avais pas totalement tort dans la mesure ou, je vous rassure, il n’est toujours pas possible de mettre plusieurs processus en écoute sur la même interface et sur le même port. En revanche, il est parfaitement possible de permettre à apache ET à sshd de recevoir des connexions, grâce à un troisième processus qui se chargera de faire le tri des connexions. Je n’ai pas encore eu le temps de tester sslh, (edit : un exemple en changeant la configuration d’apache est disponible ici), mais c’est une chose que je ferai dès que possible. EDIT : J’ai testé, ça, ça fonctionne. Même si de mon côté je trouve plus simple et plus logique de modifier le port d’écoute de démon ssh plutot que de modifier la configuration d’apache.
Clairement conçu pour permettre à une machine externe à un réseau fermé de servir de passerelle (y compris si elle utilise déjà le port 443 donc), ce logiciel ouvre des possibilités intéressantes. Il est donc possible qu’un serveur web sécurisé (https), protégé par un firewall qui ne laisserait passer que les connexions sur le 443, puisse RECEVOIR des connexions ssh. Et cela sans rien modifier de la configuration du firewall. Sympathique non ? Encore mieux… Alors qu’un tunnel ssh en mode reverse (-R), pour permettre la même chose laisserai des traces sur le firewall et sur les routeurs (connexion sortante pour établir le tunnel) cette méthode la ne laissera… aucun logs nul part. Absolument rien. Pas la moindre trace. C’est quand même fantastique tout ce qu’on peut faire avec un système unix bien configuré…
surtout qu’après on peut utilisé sa connection ssh sur le port 443 pour l’utiliser comme un proxy socks et même faire passer les requetes DNS sur ce proxy (about:config dans firefox).