Доступ К Ssh-Серверу Через Строго Регламентированное Соединение.

Эта статья – результат моего посещения автосервиса.

Ожидая машину, я подключил ноутбук к гостевой сети Wi-Fi и прочитал новости.

К своему удивлению, я обнаружил, что есть сайты, которые я не могу посетить.

Зная о шаттл (и будучи большим поклонником этого проекта) я пытался установить сеанс sshuttle со своим сервером, но безуспешно.

Порт 22 был наглухо заблокирован.

При этом nginx нормально отвечал на порту 443. Для следующего визита в автосервис я установил на сервер мультиплексор SSLH .

На сервере работает gentoo, и я добавил следующую строку в файл /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"

В зависимости от типа соединения соединения с портом 443 либо перенаправляются на локальный порт:
  • 8433 в случае https (на этом порту работает nginx)
  • 22 в случае SSH
Но когда я попытался установить ssh-соединение с сервером, мне снова не удалось.

Судя по всему фильтрация осуществлялась не только по портам, но и использовалось глубокое исследование пакетов.

Это усложняет задачу.

Ssh-трафик должен быть завернут в https. К счастью, это не сложно благодаря проекту Интернет-кошка .

На странице проекта вы можете найти множество скомпилированных двоичных файлов.

Если по каким-то причинам вы захотите собрать бинарник самостоятельно из исходников, это тоже не очень сложно.

Я делаю это с помощью упаковщика от hashicorp с такой конфигурацией:

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

Моя клиентская часть установлена на Ubuntu 20.04, сервер работает на nvidia tegra jetson tk1, поэтому для нее я делаю кросс-сборку для платформы Armv7. Обратите внимание, что сборка сервера производится без поддержки ssl, так как терминацию ssl осуществляет nginx, который обрабатывает входящие соединения.

Конфигурация nginx выглядит следующим образом:

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

Я запускаю Websocat из cron моего пользователя:

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

Теперь вы можете подключиться к вашему серверу следующим образом:

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

Насколько перенос в https снижает пропускную способность? Чтобы проверить это, я использовал эту команду:

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

В своих экспериментах я получил снижение пропускной способности в 2 раза.

При использовании протокола ws://, то есть http, пропускная способность соединения идентична необработанному ssh. Вот как вы можете настроить сеанс 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

При очередном посещении автосервиса я убедился, что все работает как надо.

В качестве приятного бонуса резко сократилось количество попыток входа на сервер по ssh с левых адресов.

Теги: #*nix #ssh

Вместе с данным постом часто просматривают: