Shellinabox является веб-клиентом для SSH. Он не обладает всеми возможностями обычной программы ssh, но может использоваться в качестве резервного варианта: на случай, если протокол ssh вдруг окажется недоступен (например, заблокирован за возможность организации туннелей), или в ситуации, когда нужно зайти на сервер, а под рукой нет SSH-клиента (впрочем, он наверняка есть на вашем компьютере, телефоне и, может быть, даже в часах).

В данной статье мы рассмотрим настройку shellinabox на примере Debian GNU/Linux и веб-сервера Apache. Мы установим пакет shellinabox и настроим Apache для доступа к shellinaboxd.

После установки и минимальной настройки вы сможете просто открыть в браузере определённую страницу на вашем сайте и увидеть там приглашение ввести логин. Для большей безопасности эту страницу можно спрятать на имеющемся сайте, точнее говоря, вносить изменения в код сайта не потребуется, просто для определённого (заведомо не существующего) адреса ваш веб-сервер будет выполнять функцию обратного прокси-сервера и обращаться к локальному адресу, на котором будет работать shellinaboxd.

Конечно для безопасной работы нужно чтобы работа с вашим сайтом осуществлялось по защищённому соединению, иначе ваши пароли могут быть перехвачены. Настройка HTTPS и получение сертификата выходит за рамки данного материала, просто упомянем, что это очень просто делается при помощи приложения certbot.

Далее предполагается, что вы зашли на сервер с правами пользователя root. Итак, сначала просто устанавливаем shellinabox:

apt install shellinabox

Программа работает на порту 4200, это почти то, что нам нужно, за исключением того, что она по умолчанию будет настроена на использование HTTPS. Поскольку защищённое соединение у нас будет обеспечивать Apache (с имеющимся сертификатом), можно переключиться на использование в shellinabox протокола HTTP, и конечно его нужно ограничить локальным интерфейсом. Добиться этого можно отредактировав файл /etc/default/shellinabox. Необходимо в опции командной строки при запуске приложения добавить ключи -t и --localhost-only, то есть, исправить в данном конфигурационном файле строку:

SHELLINABOX_ARGS="--no-beep"

В нашем случае она должна приобрести следующий вид:

SHELLINABOX_ARGS="--no-beep -t --localhost-only"

Дальше нам необходимо отредактировать конфигурацию Apache. Как уже ранее было сказано, он должен быть настроен на использование HTTPS. Также вам нужно убедиться, что установлен и подключён mod_proxy. В Debian он устанавливается в составе пакета apache2, и, если модуль отключён, вам нужно просто выполнить команду:

a2enmod proxy proxy_http

Далее в конфигурационный файл Apache нужно добавить директиву ProxyPass. Наверняка вы знаете, который из файлов в вашем случае нужно отредактировать, если вы использовали certbot, то скорее всего это будет файл с именем вида /etc/apache2/sites-available/example.com-le-ssl.conf , добавьте туда, между тегами <VirtualHost *:443> и </VirtualHost>, следующий код (поменяйте путь в теге Location):

        <Location /your/secret/path/to/web/ssh>
          ProxyPass http://127.0.0.1:4200
        </Location>

Более-менее сложный путь (в нашем примере /your/secret/path/to/web/ssh) можно рассматривать как дополнительную защиту, для того, чтобы посторонний не знал, куда подключаться, чтобы получить доступ к веб-интерфейсу для SSH (и даже не смог проверить его наличие). Совсем не обязательно, чтобы элементы пути существовали на сервере. Также вы должны быть уверены в том, что этот путь не может использоваться на вашем сайте (иначе это может помешать его нормальной работе). Защиту можно ещё усилить включив парольную аутентификацию средствами Apache.

Теперь перезапустите Apache, и shellinabox, чтобы изменения настроек вступили в силу:

systemctl restart apache2 shellinabox

Теперь по адресу вида https://example.com/your/secret/path/to/web/ssh откроется страница shellinabox, и вы сможете управлять своим сервером через веб-интерфейс, примерно как на картинке:

Конечно, чтобы когда-нибудь не оказаться перед запертой дверью, нужно не забыть пароль от вашего сервера (что при постоянном использовании ключей для аутентификации сделать достаточно просто), также следует помнить, что парольная аутентификация для пользователя root может быть отключена.

Возможно это не самое лучшее решение для обычного использования, но нельзя исключать, что в текущих условиях такой вариант поможет сохранить контроль за сервером на иностранном VPS-хостинге в случае ухудшения ситуации с блокировками.