User Tools

Site Tools


python_webssh

Python WebSSH

Перевод статьи

Обычно мы подключаемся к SSH-серверу с помощью приложения командной строки в терминале или программного обеспечения эмулятора терминала, которое включает SSH-клиент. Некоторые инструменты, такие как Python WebSSH, позволяют подключаться через SSH и запускать терминал прямо в веб-браузере.

Installing WebSSH

Если в системе установлены Python и pip, то мы можем устанавливать пакеты Python из PyPI, репозитория программного обеспечения Python. WebSSH предназначен для установки и запуска непосредственно из командной строки, поэтому нам не потребуется настраивать виртуальную среду, как обсуждалось в статье – Установка Python 3 и настройка среду программирования на сервере Ubuntu 22.04. Используем pip install для установки пакета WebSSH:

sudo pip3 install webssh

Установка через sudo приведет к глобальной установке команды wssh. Мы можем убедиться в этом, используя команду:

which wssh
/usr/local/bin/wssh

Как видим, WebSSH установлен. Далее, мы запустим и подключитесь к нему. Однако сначала нужно добавить правило брандмауэра. По умолчанию WebSSH работает на порту 8888. Если вы используете ufw в качестве брандмауэра, откроем этот порт:

sudo ufw allow 8888

Running and Connecting to WebSSH

Если вы используете WebSSH на локальном хосте, то никакие дополнительные аргументы не потребуются. Если же, запускаем WebSSH на удаленном сервере, следует добавить флаг –fbidhttp=False, чтобы разрешить удаленные соединения по-обычному HTTP. Это небезопасно, если вы подключаетесь по незащищенной сети, но это полезно для демонстрации. Об обеспечение безопасности – поговорим ниже.

wssh --fbidhttp=False

Теперь можно подключиться к WebSSH и войти в систему. Перейдем по адресу http://your_domain:8888 в веб-браузере и увидим страницу входа в WebSSH:


Указываем нужные данные и входим в shell.

Securing WebSSH with an SSL Certificate

Для выполнения этой задачи, мы должны получит SSL-сертификат для своего доменного имени. Один из способов сделать это – использовать LetsEncrypt в автономном режиме.

По умолчанию, LetsEncrypt хранит полученные сертификаты в /etc/letsencrypt/live/your_domain. Посмотрим, на месте ли они:

sudo ls /etc/letsencrypt/live/your_domain
README  cert.pem  chain.pem  fullchain.pem  privkey.pem

Чтобы запустить WebSSH с поддержкой HTTPS, вам нужно указать путь к сертификату и путь к ключу. Это fullchain.pem и privkey.pem. По умолчанию WebSSH предоставляет доступ к HTTPS через порт 4433, поэтому откроем и этот порт в брандмауэре:

sudo ufw allow 4433

Далее, запускаем WebSSH с путями к сертификату и ключу:

sudo wssh --certfile='/etc/letsencrypt/live/your_domain/fullchain.pem' --keyfile='/etc/letsencrypt/live/your_domain/privkey.pem'

Теперь подключение будет происходить по адресу https://your_domain:4433, но уже с поддержкой HTTPS. Теперь этого достаточно для безопасной производственной конфигурации. Однако, мы все еще запускаете wssh непосредственно из терминала, а доступ к нему в браузере осуществляется через необычный порт. Далее, займемся тем, что устраним оба этих ограничения.

Running WebSSH Behind an Nginx Reverse Proxy

Размещение веб-сервера, такого как Nginx, перед другими веб-приложениями может повысить производительность и значительно упростить их защиту. Давайте установим Nginx и настроите его на обратное проксирование запросов к WebSSH, то есть он будет обрабатывать запросы от пользователей к WebSSH и обратно.

Установим nginx:

sudo apt update nginx
sudo apt install nginx

Если используется брандмауэр ufw, следует внести некоторые изменения в конфигурацию брандмауэра на этом этапе, чтобы обеспечить доступ к стандартным портам HTTP/HTTPS, 80 и 443. ufw имеет стоковую конфигурацию под названием Nginx Full, которая обеспечивает доступ к обоим этим портам:

sudo ufw allow “Nginx Full”

Создадим новую конфигурацию nginx /etc/nginx/sites-available/webssh:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name your_domain www.your_domain;
    root /var/www/html;
 
    access_log /var/log/nginx/webssh.access.log;
    error_log /var/log/nginx/webssh.error.log;
 
    location / {
        proxy_pass http://127.0.0.1:8888;
        proxy_http_version 1.1;
        proxy_read_timeout 300;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Real-PORT $remote_port;
    }
 
    listen 443 ssl;
    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;
 
    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

Рассмотрим выше приведенную конфигурацию, как видим, она состоит из трех блоков. Первый блок, идущий перед строкой location /, содержит стандартную конфигурацию Nginx для обслуживания веб-сайта через HTTP-порт по умолчанию: 80. Блок location / содержит конфигурацию для проксирования входящих соединений на WebSSH, работающий на внутреннем порту 8888. Конфигурация в конце файла, после блока location / загружает ваши пары SSL-ключей LetsEncrypt и перенаправляет HTTP-соединения на HTTPS.

Далее нужно активировать новую конфигурацию. Активация конфигурации Nginx, заключается в создании символических ссылок, из директории в sites-available/ в каталог sites-enabled/. Для примера, используем полные пути, создадим ссылку:

sudo ln -s /etc/nginx/sites-available/webssh /etc/nginx/sites-enabled/webssh

По умолчанию, Nginx использует другой файл конфигурации – /etc/nginx/sites-available/default, связанный с /etc/nginx/sites-enabled/default, который также служит страницей по умолчанию. Мы можем отключить это правило, удалив его из /sites-enabled, поскольку он может конфликтовать с нашей новой конфигурацией WebSSH:

sudo rm /etc/nginx/sites-enabled/default

Проверяем конфиги:

sudo nginx -t

Если все ок, перезапускаем демон nginx:

sudo systemctl restart nginx

Наконец, мы можем удалить созданные ранее правила брандмауэра для прямого доступа к WebSSH, поскольку теперь весь трафик будет обрабатываться Nginx через стандартные порты HTTP/HTTPS:

sudo ufw delete allow 8888
sudo ufw delete allow 4433

Перезапустим webssh:

wssh

На этот раз, нам не нужно указывать пути к сертификату и ключу, так как теперь, это обрабатывает Nginx.

Creating a Systemd Service for WebSSH

Развертывание серверного приложение, подразумевает его автоматический запуск. Для решения этого вопроса, мы создадим unit file, который будет использоваться системой инициализации нашего сервера. Почти во всех современных дистрибутивах Linux система инициализации называется Systemd. Взаимодействие с ней, происходит с помощью команды systemctl.

Остановим WebSSH и создадим файл юнита – /etc/systemd/system/webssh.service. Редактируем его. Юнит, должен содержать, как минимум три раздела: [Unit], [Service] и [Install]:

[Unit]
Description=WebSSH terminal interface
After=network.target
 
[Service]
User=www-data
Group=www-data
ExecStart=wssh
 
[Install]
WantedBy=multi-user.target

Подробнее о разделах:

  • [Unit] – содержит текстовое описание службы, а также хук After, который указывает, когда она должна быть запущена при старте системы, в данном случае после того, как заработают сетевые интерфейсы сервера.
  • [Service] – указывает, какая команда должна быть запущена, а также какой пользователь должен ее выполнять. В данном случае www-data - это пользователь Nginx по умолчанию, а wssh – это сама команда.
  • [Install] – этот раздел, содержит только строку WantedBy=multi-user.target, которая работает вместе с хуком After в разделе [Unit] для обеспечения запуска службы, когда сервер готов принимать логины пользователей.

Стартуем и добавляем демон в автозагрузку:

sudo systemctl start webssh
sudo systemctl enable webssh

И проверяем корректность работы демона:

sudo systemctl status webssh

Теперь, WebSSH будет доступен по адресу: https://your_domain

python_webssh.txt · Last modified: 2023/04/06 10:28 (external edit)