Clever Geek Handbook

Accéder au serveur ssh via une connexion très encombrée

Cet article est le résultat de ma visite dans un service automobile. En attendant la voiture, j'ai connecté mon ordinateur portable au réseau wifi invité et j'ai lu l'actualité. À ma grande surprise, j'ai constaté que je ne pouvais pas visiter certains sites. Connaissant sshuttle (et étant un grand fan de ce projet), j'ai essayé d'établir une session sshuttle avec mon serveur, mais cela n'a pas fonctionné. Le port 22 était étroitement bloqué. Dans le même temps, nginx sur le port 443 a répondu normalement. Lors de la prochaine visite au service de voiture, j'ai installé le multiplexeur sslh sur le serveur .Le serveur exécute gentoo et j'ai ajouté la ligne suivante au fichier /etc/conf.d/sslh: 



DAEMON_OPTS="-p 0.0.0.0:443 --ssl 127.0.0.1:8443 --ssh 127.0.0.1:22 --user nobody"


Selon le type de connexion, les connexions au port 443 sont soit transférées vers le port local:



  • 8433 en cas de https (nginx fonctionne sur ce port)
  • 22 en cas de ssh


Mais quand j'ai essayé d'établir une connexion ssh avec le serveur, j'ai de nouveau échoué. Apparemment, le filtrage a été effectué non seulement par les ports, mais une investigation approfondie des paquets a également été utilisée. Cela rend la tâche plus difficile. Le trafic SSH doit être enveloppé dans https. Heureusement, ce n'est pas difficile grâce au projet websocat . Sur la page du projet, vous pouvez trouver de nombreux binaires prédéfinis. Si, pour une raison quelconque, vous souhaitez compiler vous-même le binaire à partir des sources, ce n'est pas non plus très difficile. Je fais cela avec le packer de hashicorp en utilisant la configuration suivante: 



{
  "min_packer_version": "1.6.5",
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:20.04",
      "privileged": true,
      "discard": true,
      "volumes": {
        "{{pwd}}": "/output"
      }
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "skip_clean": true,
      "environment_vars": [
        "DEBIAN_FRONTEND=noninteractive"
      ],
      "inline": [
        "apt-get update && apt-get install -y git curl gcc libssl-dev pkg-config gcc-arm-linux-gnueabihf",
        "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs >/tmp/rustup.sh && chmod +x /tmp/rustup.sh && /tmp/rustup.sh -y",
        "git clone https://github.com/vi/websocat.git && cd websocat/",
        ". $HOME/.cargo/env && cargo build --release --features=ssl",
        "printf '[target.armv7-unknown-linux-gnueabihf]\nlinker = \"arm-linux-gnueabihf-gcc\"\n' >$HOME/.cargo/config",
        "rustup target add armv7-unknown-linux-gnueabihf",
        "cargo build --target=armv7-unknown-linux-gnueabihf --release",
        "strip target/release/websocat",
        "tar czf /output/websocat.tgz target/armv7-unknown-linux-gnueabihf/release/websocat target/release/websocat",
        "chown --reference=/output /output/websocat.tgz"
      ]
    }
  ]
}


Le côté client est sur ubuntu 20.04, le serveur fonctionne sur nvidia tegra jetson tk1, donc pour cela, je fais un assemblage croisé pour la plate-forme armv7. Veuillez noter que la construction du serveur se fait sans le support ssl, puisque la terminaison SSL pour moi est effectuée par nginx, qui traite les connexions entrantes. La configuration nginx ressemble à ceci: 



http {
    server {
        listen 0.0.0.0:8443 ssl;
        server_name your.host.com;
        ssl_certificate /etc/letsencrypt/live/your.host.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your.host.com/privkey.pem;
        location /wstunnel/ {
            proxy_pass http://127.0.0.1:8022;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
        }
    }
}


Je lance Websocat depuis la couronne de mon utilisateur: 



* * * * * netstat -lnt|grep -q :8022 || $HOME/bin/websocat -E --binary ws-l:127.0.0.1:8022 tcp:127.0.0.1:22|logger -t websocat &


Vous pouvez maintenant vous connecter à votre serveur comme ceci: 



ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com


Dans quelle mesure le wrapping en https réduit-il la bande passante? Afin de vérifier cela, j'ai utilisé la commande suivante: 



ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com 'dd if=/dev/zero count=32768 bs=8192' >/dev/null


Dans mes expériences, j'ai obtenu une réduction de 2 fois de la bande passante. Lors de l'utilisation du protocole ws: //, c'est-à-dire http, la bande passante de connexion est identique à celle de ssh non enveloppé.



Voici comment configurer une session sshuttle: 



sshuttle -e 'ssh -o ProxyCommand="websocat --binary wss://your.host.com/wstunnel/"' -r your.host.com 0/0 -x $(dig +short your.host.com)/32


Lors de la prochaine visite au service de voiture, je me suis assuré que tout fonctionne comme il se doit. En prime, le nombre de tentatives de connexion au serveur via ssh à partir des adresses de gauche a fortement chuté.


More articles:


All Articles