Наведений варіант налаштування хоч і має деякий умовний ступінь захисту від сторонніх, проте він не передбачає публічного використання, включаючи звичайних користувачів, він розглядається як запасний канал управління для домашнього сервера і тільки для нього у випадку, якщо штатні та надійні канали немає можливості використовувати, наприклад, якщо доступний лише браузер у телефоні. Хоча, для телефону є інші варіанти, той же 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. Елегантно? Елегантно.
Звичайно, поверх цього можна спорудити додаткові засоби та механізми як для обмеження, так і для розширення повноважень користувача у системі.