How to access ssh terminal in web browser on Linux

Running "everything" in a web browser used to be a bold statement. However, due to the powerful HTML5/JavaScript stack, a web browser increasingly becomes a dominant application delivery platform. Even the Linux kernel sandboxed in a web browser no longer sounds so crazy these days.

In this tutorial, I describe how to access an SSH terminal in a web browser on Linux. Web-based SSH is useful when the firewall you are behind is so restrictive that only HTTP(s) traffic can get through.

Shell In A Box (or shellinabox) is a web-based terminal emulator which can run as a web-based SSH client. It comes with its own web server (shellinaboxd) which exports a command line shell to a web-based terminal emulator via AJAX interface. Shell In a Box only needs JavaScript/CSS support from a web browser, and does not require any additional browser plugin.

Install Shell In A Box on Linux

To install shellinabox on Debian, Ubuntu or Linux Mint:

$ sudo apt-get install openssl shellinabox

To install shellinabox on Fedora:

$ sudo yum install openssl shellinabox

To install shellinabox on CentOS or RHEL, first enable EPEL repository, and then run:

$ sudo yum install openssl shellinabox

Configure Shellinaboxd Web Server

By default shellinaboxd web server listens on 4200 TCP port on localhost. In this tutorial, I change the default port to 443 for HTTPS. For that, modify shellinabox configuration as follows.

Configure shellinaboxd On Debian, Ubuntu or Linux Mint:

$ sudo vi /etc/default/shellinabox
# TCP port that shellinboxd's webserver listens on
SHELLINABOX_PORT=443

# specify the IP address of a destination SSH server
SHELLINABOX_ARGS="--o-beep -s /:SSH:192.168.1.7"

# if you want to restrict access to shellinaboxd from localhost only
SHELLINABOX_ARGS="--o-beep -s /:SSH:192.168.1.7 --localhost-only"

Configure shellinaboxd On Fedora, CentOS or RHEL:

$ sudo vi /etc/sysconfig/shellinaboxd
# TCP port that shellinboxd's webserver listens on
PORT=443

# specify the IP address of a destination SSH server
OPTS="-s /:SSH:192.168.1.7"

# if you want to restrict access to shellinaboxd from localhost only
OPTS="-s /:SSH:192.168.1.7 --localhost-only"

Heads-up for Fedora users: According to the official document, some operations may not work out of the box when you run shellinaboxd in SELinux mode on Fedora. Refer to the document if you have any issue.

Provision a Self-Signed Certificate

During the installation of Shell In A Box, shellinaboxd attempts to create a new self-signed certificate (certificate.pem) by using /usr/bin/openssl if no suitable certificate is found on your Linux. The created certificate is then placed in /var/lib/shellinabox.

If no certificate is found in the directory for some reason, you can create one yourself as follows.

$ su (change to the root)
# cd /var/lib/shellinabox
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
# cat server.crt server.key > certificate.pem

Run Shellinaboxd Web Server

On Debian, Ubuntu or Linux Mint:

$ sudo service shellinabox start

On Fedora, CentOS or RHEL:

$ sudo systemctl enable shellinaboxd.service
$ sudo systemctl start shellinaboxd.service

To verify if shellinaboxd is running:

$ sudo netstat -nap | grep shellinabox
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4787/shellinaboxd

Now open up your web browser, and navigate to https://<IP_address_of_SSH_server>. You should be able to see a web-based SSH console, and log in to the remote SSH server via web browser interface.


Subscribe to Xmodulo

Do you want to receive Linux FAQs, detailed tutorials and tips published at Xmodulo? Enter your email address below, and we will deliver our Linux posts straight to your email box, for free. Delivery powered by Google Feedburner.

The following two tabs change content below.
Dan Nanni is the founder and also a regular contributor of Xmodulo.com. He is a Linux/FOSS enthusiast who loves to get his hands dirty with his Linux box. He likes to procrastinate when he is supposed to be busy and productive. When he is otherwise free, he likes to watch movies and shop for the coolest gadgets.

11 thoughts on “How to access ssh terminal in web browser on Linux

    • Yes, but with that nacl Chrome extension you have to have access to port 22 on the outside. If you are in a corporate environment you are only getting port 80 and 443. So with this you can circumvent the problem.

  1. A nifty idea to be able to access SSH from the browser. However, it may also invite someone to log in from a compromised/keylogged system more easily.

    There are cases where I just have SSH itself listening on port 443. Never had trouble with that in corporate environments.

  2. How would you compare the interface with FireSSH?

    For that matter, I don't see the advantage of running a separate daemon over a firefox add-on which requires no daemon. Any comments on FireSSH vs. shellinaboxd plus browser?

    • First of all, cross-browser support (no requirement for a plugin) is a big thing. The advantage of having a separate daemon is the ability to bypass restrictive firewall rules.

  3. Why would someone want to expose the system to the world that way?
    It's not that hard to run SSH server on port 443 and access it through the small putty ssh client tool, why to install more stuff?

  4. Not seeing the point. All this is going to give you is a tty in a browser window pointing to a server running ssh. Pardon me if this actually tries to run more than a terminal emulator in the browser, but there is zero logical reason to. No real point to running ssh at all in that environment, might as well just connect to a ptty and run login on it.

    The advantages of ssh are:

    1. secure traffic, pointless since the whole link is protected by ssl already. Https uses most of the same crypto goodness as ssh so it is good enough as is.

    2. Passwordless login. Not possible with this.

    3. Port redirection and all of the other ssh goodness. Not possible with this.

    Just have sshd listen on the https/443 port and have done with it if the point is traversing overly paranoid firewalls. If the firewall is inspecting hard enough to tell the difference between ssh and https you probably shouldn't be trying to defeat it anyway. Somebody really doesn't want you doing what you are trying to do and you obviously aren't the admin. If the point is the client workstation is brain damaged, only offering a web broser, fix it or replace it.

    So 6 outta ten points for the 'watch me do this' factor, but Meh on utility.

    Oh, and Fedora still offers the service command and aliases to systemctl. CentOS 6 and RHEL 6 don't have systemd at all, when RHEL 7 drops it might. So you can simplify your instructions a bit.

    • "Just have sshd listen on the https/443 port and have done with it if the point is traversing overly paranoid firewalls. If the firewall is inspecting hard enough to tell the difference between ssh and https you probably shouldn’t be trying to defeat it anyway. Somebody really doesn’t want you doing what you are trying to do and you obviously aren’t the admin. " - John Morris

      Two contradictory statements in a single paragraph, one talking about how you bypass firewalls that block port 22 using port 443, and the other saying you shouldn't bypass firewalls if you aren't the admin (just because the solution happens to be the one in the article that you just need to be against).

      Majority of firewalls nowadays (like Sonicwall, fortinet) inspect the packet type. And there are also a LOT of companies that block port 80 & 443 and only allow access through a proxy. This is brilliant in those cases.

      But just because you aren't in such a network, this application is 'meh' on utility? What would you say if you were in such a network? Don't bypass the firewall, just to avoid prasing what is obviously a very well written utility? Then you shouldn't be running SSH on port 443 now.

  5. Looks interesting: I have a webapp running in a multiblade chassis that might be enhanced with this.
    My users are limited to FF/Chrome, and we have no idea at all what equipment/OS or network they might use to get to the website. It would be more elegant to provide access from within the app, rather than forcing them out to a terminal. Especially as they might have 100 VMs to manage using DHCP - hard to keep track outside the webapp.

  6. This is actually useful in several situations and removes the need to have an SSH client at all. Thanks for the info.

Leave a comment

Your email address will not be published. Required fields are marked *

Current ye@r *