Shellinabox – if SSH is suddenly blocked

Shellinabox is a web client for SSH. It does not have all the features of a regular ssh program, but can be used as a fallback option: in case the ssh protocol suddenly turns out to be unavailable (for example, blocked for the ability to establish tunnels), or in a situation where you need to go to the server, but there is no SSH client (however, you probably have it on your computer, phone, and maybe even on your watch).

In this article, we’ll look at setting up shellinabox using Debian GNU/Linux and the Apache web server as an example. We will install the shellinabox package and configure Apache to access shellinaboxd.

After installation and minimal configuration, you can simply open a specific page on your site in your browser and see an invitation to login there. For greater security, this page can be hidden on an existing site, more precisely, you won’t need to make changes to the site code, just for a certain (obviously non-existent) address, your web server will act as a reverse proxy server and access the local address where shellinaboxd will work.

Of course, for safe work, you need to work with your site over a secure connection, otherwise your passwords can be intercepted. Setting up HTTPS and obtaining a certificate is beyond the scope of this article, just to mention that it is very easy to do with the certbot application.

The following assumes that you are logged into the server as root. So first, just install shellinabox:

apt install shellinabox

The program runs on port 4200, which is pretty much what we want, except that it will be configured to use HTTPS by default. Since Apache will provide a secure connection (with an existing certificate), you can switch to using the HTTP protocol in shellinabox, and of course it needs to be limited to the local interface. This can be achieved by editing the file /etc/default/shellinabox. It is necessary to add keys in the command line option when starting the application -t and --localhost-onlythat is, correct the line in this configuration file:

SHELLINABOX_ARGS="--no-beep"

In our case, it should take the following form:

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

Next, we need to edit the Apache configuration. As previously stated, it must be configured to use HTTPS. You also need to make sure that mod_proxy is installed and enabled. On Debian, it is installed as part of the apache2 package, and if the module is disabled, you just need to run the command:

a2enmod proxy proxy_http

Next, in the Apache configuration file, you need to add the directive ProxyPass. Surely you know which of the files in your case you need to edit, if you used certbot, then most likely it will be a file with a name like /etc/apache2/sites-available/example.com-le-ssl.conf , add there, between tags <VirtualHost *:443> and </VirtualHost>the following code (change the path in the Location tag):

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

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

Now restart Apache and shellinabox for the configuration changes to take effect:

systemctl restart apache2 shellinabox

Now the shellinabox page will open at https://example.com/your/secret/path/to/web/ssh and you will be able to manage your server via the web interface, like in the picture:

Of course, in order not to find yourself in front of a locked door someday, you need to remember the password from your server (which is quite easy to do if you constantly use keys for authentication), you should also remember that password authentication for the root user can be disabled.

This may not be the best solution for normal use, but it cannot be ruled out that in the current conditions this option will help maintain control over the server on a foreign VPS hosting in case the blocking situation worsens.