Приведённый вариант настройки хоть и имеет некоторую условную степень защиты от посторонних, тем не менее он не предполагает публичного использования, включая обычных пользователей, он рассматривается как запасной канал управления для домашнего сервера и только для него в случае, если штатные и надёжные каналы нет возможности использовать, например, если доступен только браузер в телефоне. Хотя, для телефона есть другие варианты, тот же Termux, и телефон не может в полной мере являться доверенным устройством, тем не менее, пример есть пример.
Несмотря на то, что сам wssh-клиент может использовать one-time-password, основной защитой должен являться nginx с auth_basic и связкой логин-пароль для location /webssh/ которые я советую генерировать новые после использования старых. Так как они могут быть использованы для авторизации с оборудования к которому нет полного доверия. Так, конечно же, делать ни в коем случае не надо. Но если очень хочется, что-то включить/выключить/перезапустить, то можно.
Начнём
Задача, иметь возможность использовать ssh в условиях недоступности полноценной и защищённой рабочей среды (ноут, openvpn, ssh), а веб-интерфейс управления, или из существующих, или самописный всё равно не даёт всех возможностей интерактивной консоли.
Выбрана наиболее компактная и развиваемая реализация клиента на python.
Согласно документации, блок-схема связей работает следующим образом.
В этом случае клиент wssh может подключиться к любому серверу, включая локальный, используя при подключении любой логин. Но цель ограничить работу по ssh только с локальным сервером, при этом авторизуясь пользователем с ограниченными возможностями доступа к внешней сети.
location/webssh/{rewrite/webssh/(.*)/$1break;client_body_buffer_size4k;client_max_body_size512k;keepalive_timeout240s;keepalive_requests100;send_timeout30s;# Время активности неактивной консоли, подключение будет сброшено при отсутствии активности.client_body_timeout30s;more_set_headers"X-Frame-Options:SAMEORIGIN";more_set_headers"X-Content-Type-Options:nosniff";more_set_headers"X-XSS-Protection:\"1;mode=block\"";more_set_headers"Strict-Transport-Security:\"max-age=31536000;includeSubdomains;preload\"always";auth_basic"ACCESS";auth_basic_user_file/etc/nginx/auth/domain-webssh.pwd;# deny all;proxy_intercept_errorsoff;proxy_passhttp://127.0.0.1:2222;# websshproxy_http_version1.1;proxy_read_timeout120;proxy_set_headerUpgrade$http_upgrade;# http://nginx.org/ru/docs/http/websocket.htmlproxy_set_headerConnection"upgrade";# ^proxy_set_headerHost$http_host;proxy_set_headerX-Real-IP$remote_addr;proxy_set_headerX-Real-PORT$remote_port;proxy_set_headerX-Forwarded-For$remote_addr;proxy_redirectoff;proxy_set_headerProxy"";}
wssh backend
Кому как удобней запускать демона, здесь я использую собственные скрипты/вочдоги, набросок:
Таким образом, python-клиент wssh (который является backend сервером для nginx) запущен от пользователя webssh, которому запрещены любые соединения, кроме 127.0.0.1.
Этот самый wssh-клиент может подключиться к серверному ssh-демону используя логин webssh и заданный пароль, для доступа к странице можетдолжен использоватся другой логин и другой пароль, заданный в auth_basic_user_file /etc/nginx/auth/domain-webssh.pwd. Изящно? Изящно.
Конечно, поверх этого можно соорудить дополнительные средства и механизмы, как для ограничения, так и для расширения полномочий пользователя в системе.