Clever Geek Handbook

Accediendo al servidor ssh a través de una conexión muy congestionada

Este artículo es el resultado de mi visita a un servicio de automóviles. Mientras esperaba el auto, conecté mi computadora portátil a la red wifi para invitados y leí las noticias. Para mi sorpresa, descubrí que no podía visitar algunos sitios. Sabiendo sobre sshuttle (y siendo un gran fan de este proyecto) intenté establecer una sesión de sshuttle con mi servidor, pero no funcionó. El puerto 22 estaba firmemente bloqueado. Al mismo tiempo, nginx en el puerto 443 respondió normalmente. En la siguiente visita al servicio de automóviles, instalé el multiplexor sslh en el servidor .El servidor está ejecutando gentoo y agregué la siguiente línea al archivo /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"


Dependiendo del tipo de conexión, las conexiones al puerto 443 se reenvían al puerto local:



  • 8433 en el caso de https (nginx se está ejecutando en este puerto)
  • 22 en caso de ssh


Pero cuando intenté establecer una conexión SSH con el servidor, volví a fallar. Aparentemente, el filtrado se llevó a cabo no solo por puertos, sino que también se utilizó la investigación profunda de paquetes. Esto dificulta la tarea. El tráfico SSH debe estar envuelto en https. Afortunadamente, esto no es difícil gracias al proyecto websocat . En la página del proyecto, puede encontrar muchos binarios compilados. Si por alguna razón desea compilar el binario usted mismo desde la fuente, esto tampoco es muy difícil. Hago esto con el empaquetador de hashicorp con la siguiente configuración: 



{
  "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"
      ]
    }
  ]
}


El lado del cliente está en ubuntu 20.04, el servidor se ejecuta en nvidia tegra jetson tk1, por lo que estoy haciendo un ensamblaje cruzado para la plataforma armv7. Tenga en cuenta que la compilación del servidor se realiza sin soporte ssl, ya que la terminación ssl para mí la realiza nginx, que procesa las conexiones entrantes. La configuración de nginx se ve así: 



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";
        }
    }
}


Ejecuto Websocat desde la corona de mi usuario: 



* * * * * 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 &


Ahora puede conectarse a su servidor de esta manera: 



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


¿Cuánto reduce el ancho de banda el envolver en https? Para verificar esto, utilicé el siguiente comando: 



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


En mis experimentos, obtuve una reducción de 2x en el ancho de banda. Cuando se utiliza el protocolo ws: //, es decir http, el ancho de banda de la conexión es idéntico al ssh sin empaquetar.



Así es como puede configurar una sesión 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


En la siguiente visita al servicio de automóviles, me aseguré de que todo funcionara como debería. Como una buena ventaja, el número de intentos de iniciar sesión en el servidor a través de ssh desde las direcciones de la izquierda se redujo drásticamente.


More articles:


All Articles