[*nix] Доступ к ssh серверу через очень зарегулированное подключение
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Эта статья является результатом посещения мной автосервиса. В ожидании машины я подключил свой ноутбук к гостевой wifi-сети и читал новости. К своему удивлению я обнаружил, что некоторые сайты я посетить не могу. Зная про sshuttle (и будучи большим поклонником этого проекта) я попытался установить 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 соединение с сервером меня опять постигла неудача. Видимо фильтрация осуществлялась не просто по портам, но также использовался deep packet investigation. Таким образом задача усложняется. Ssh трафик надо обернуть в https. К счастью это не сложно благодаря проекту websocat. На странице проекта вы можете найти много собранных бинарников. Если по какой-то причине вы хотите собрать бинарник самостоятельно из исходников это тоже не очень сложно. Я делаю это при помощи packer от 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 termination у меня осуществляет 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 я запускаю из крона своего юзера:
* * * * * 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 с левых адресов.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, *nix] FOSS News №45 – дайджест новостей и других материалов о свободном и открытом ПО за 30 ноября — 6 декабря 2020 года
- [Информационная безопасность, Системное администрирование, IT-инфраструктура, Серверное администрирование] Как настроить SSH-Jump Server
- [Open source, *nix] FOSS News №44 – дайджест новостей и других материалов о свободном и открытом ПО за 23-29 ноября 2020 года
- [Информационная безопасность, *nix] Как *nix-сигналы позволяют читать память других процессов
- [IT-инфраструктура, Стандарты связи, Лайфхаки для гиков] 5 приемов и хитростей для работы с SSH и кое-что еще (перевод)
- [*nix] Использование локального .bashrc через ssh и консолидация истории выполнения команд
- [Программирование, *nix, C] Bison, dynamic linking и… обработка BMP изображений
- [Open source, *nix] FOSS News №43 – дайджест новостей и других материалов о свободном и открытом ПО за 16-22 ноября 2020 года
- [Настройка Linux, *nix, Разработка под Android, Разработка под Linux] Разработка приложения с использованием Python и OpenCV на Android устройстве
- [Системное администрирование] CIFS over SSH штатными средствами Windows 10
Теги для поиска: #_*nix, #_ssh, #_*nix
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:38
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Эта статья является результатом посещения мной автосервиса. В ожидании машины я подключил свой ноутбук к гостевой wifi-сети и читал новости. К своему удивлению я обнаружил, что некоторые сайты я посетить не могу. Зная про sshuttle (и будучи большим поклонником этого проекта) я попытался установить 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 либо пробрасываются на локальный порт
{
"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 termination у меня осуществляет 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 я запускаю из крона своего юзера: * * * * * 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 с левых адресов. =========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:38
Часовой пояс: UTC + 5