Running "everything" in a web browser used to be a bold statement. Due to the powerful HTML5/JavaScript stack, however, 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:
To install shellinabox on Fedora:
To install shellinabox on CentOS or RHEL, first enable EPEL repository, and then run:
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:
# 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:
# 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.
# 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:
On Fedora, CentOS or RHEL:
$ sudo systemctl start shellinaboxd.service
To verify if shellinaboxd is running:
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.
Have a comment that we are gonna see a lot here, I'm afraid: "Chrome/Google has an app for that." ;-)
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.
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.
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.
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?
because in a short while you are not going to be able to run putty anymore because desktops are obsolete.
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.
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.
This is actually useful in several situations and removes the need to have an SSH client at all. Thanks for the info.
Thanks. It works. It is perfect for my requirement.
A few days ago I installed this: Web Console (http://www.web-console.org)
Really useful tool.