Web-based SSH

Web-based SSH makes it possible to access Secure Shell (SSH) servers through standard web browsers. Respective clients are typically based on JavaScript/Ajax or JavaScript/WebSockets, and, if they work together with an Ajax/WebSocket-to-SSH proxy, can be used to access SSH servers from behind a firewall or proxy that allows HTTP traffic but does not allow SSH traffic.

Technology

Web-based SSH clients basically consist of the following parts:

Client-side: Typically JavaScript and dynamic HTML pages are used to capture keystrokes, transmit messages to/from the server and display the results in the user's web browser.
Server-side/Web application: Incoming requests are processed on the web application server. Keyboard events are forwarded to a secure shell client communicating with the connected SSH server. Terminal output is either passed to the client where it is converted into HTML via JavaScript or it is translated into HTML by the server before it is transmitted to the client.

Client-side terminal emulation

Web-based SSH servers that utilize client-side terminal emulation typically transmit the raw terminal output from the SSH server directly to the client. This has the advantage of offloading the process of translating terminal output into HTML on to the client. The disadvantage of this method is that it is limited by the capabilities of JavaScript and it will use up a non-trivial amount of the client's CPU and memory to process the incoming character stream. It also relies on the client to keep track of the terminal state and respond to escape sequences.

Client-side terminal emulator example: vt100.js (from Shell in a Box)

Server-side terminal emulation

Web-based SSH servers that utilize server-side terminal emulation typically keep track of the terminal screen and state in memory and convert it to HTML either when a screen update occurs or when the client expressly requests an update. The advantage of this method is that the state of the terminal remains persistent even if the user connects to their existing session(s) from a different web browser. It also enables the server to act upon terminal output even if the user is disconnected.^[1] The disadvantage of this method is that it uses up more CPU and memory on the server.

Server-side terminal emulator example: terminal.py (From Gate One).

Advantages

The main advantages of web-based SSH can be summarized as follows:

Accessibility: Web-based SSH as described in this article requires no local installation of client software. It is thus possible to access SSH servers through a web browser from anywhere. As communication is based on HTTP or HTTPS it is also possible to access SSH servers from behind a firewall or proxy that restricts Internet access to only ports 80 (HTTP) or 443 (HTTPS).
Anonymous Access: As SSH access is tunneled through an intermediary web application server it is this server which actually communicates with the SSH server. This means that the SSH server will only be aware of the IP address of the web application server, keeping the actual client's IP address hidden.
Auditability: Because all communication between the client and the SSH server must pass through the web application server this communication can be logged. This prevents a malicious client from deleting logs of their activities. The situation is exactly the same as with traditional SSH server.
Resuming Sessions: Some web-based SSH implementations allow the user to resume their SSH sessions after being disconnected. This is not possible with a traditional SSH client.
Embeddable: Web-based SSH implementations can be embedded into any web page allowing them to be integrated into other web-based applications.
Unique Features: Many web-based SSH tools have unique features such as the ability to share terminals with other users, can display images within terminals, and other useful capabilities.

Important issues

The following issues have to be considered and are important when using a web-based SSH client:

Security: It is important to make sure that HTTPS is used when communicating with the web application server. Otherwise all data being sent would be readable by use of simple packet sniffers which could reveal sensitive information.
Trust: The data being sent to the web application server is decrypted there. This is necessary in order to forward the issued commands to the actual SSH server. Even though the operators of web-based SSH solutions usually don't log sensitive data the data is theoretically available to them in plain form. It is unlikely that this will cause a security issue when the web application server and the SSH server are run on the same server or are controlled by the same entity.
Tunneling: Unlike traditional application based SSH clients, web-based SSH clients are unable to tunnel ("forward") TCP traffic. For example, running an X Window session over a web-based SSH session is not possible.

Open source examples

Google's Secure Shell extension for Chrome and Chromium pairs the JavaScript hterm terminal emulator with OpenSSH client code running on Native Client.^[2] The Secure Shell extension does not itself work with non-Google HTTP-to-SSH proxies, but provides proxy hooks, and the third-party application nassh-relay^[3] can use those hooks to enable the Secure Shell extension to establish an SSH connection over XMLHttpRequest or WebSocket transport. Since the SSH protocol encryption/decryption and terminal emulation happens entirely client-side (i.e. within the web browser - inside of the Native Client OpenSSH instance) the risk of using a third-party proxy is minimal - provided you manually verify the SSH server's fingerprint the first time you connect to it, otherwise you are at risk of a man-in-the-middle attack by (among others) the proxy provider. The proxy will only have access to the encrypted data stream, which even when using non-browser based SSH is also visible to (at least) all ISPs between you and the destination server. However, using a proxy is only required if your browser is somehow blocked/firewalled off from accessing the SSH server directly (excessively restrictive government and corporate firewalls come to mind).

Anyterm is written in C++ (server side) and JavaScript (client) and utilizes server-side^[4] terminal emulation. It utilizes long polling for client/server communication. The server-side implementation is a stand-alone daemon which is typically used with a reverse proxy, such as Apache's mod_proxy. Anyterm is licensed under the terms of GPL.

Ajaxterm is written in Python (server side) and JavaScript (client) and utilizes server-side terminal emulation. Screen updates are performed by repeated HTTP requests. Each reply is a full screen actualization. If there are no screen changes to transfer, the data to be sent are minimal. Ajaxterm operates as a stand-alone daemon and can also be placed behind a reverse proxy. It is in the public domain.

Gate One is also written in Python (server side) and JavaScript (client). It uses server-side terminal emulation and WebSockets for client/server communication. It operates as a stand-alone daemon but can be placed behind any proxy that supports WebSockets. It is dual-licensed under the terms of the AGPLv3 with a commercial license available for purchase.

webmux is written in Python (server side) and JavaScript (client) as well. It uses WebSockets, server-side terminal emulation and an SSH client (using Twisted (software)). It is licensed under the terms of the MIT License.

WebShell extends Ajaxterm by adding an on-screen graphical keyboard which is intended for touchscreen mobile devices.

EC2Box is written in Java (server side) and JavaScript (client). Commands can be execute on multiple terminals simultaneously to EC2 instances running on Amazon Web Services. Two-factor authentication using one-time passwords. Licensed under the Apache License version 2.0.

KeyBox is written in Java (server side) and JavaScript (client). The SSH servers used for terminal emulation are defined within the application. Users can be created, managed, and assigned to system profiles. Two-factor authentication using one-time passwords. Also, can be used to manage public SSH keys for its users or setup as a bastion host. Licensed under the Apache License version 2.0.

KeyBox-OpenShift is written in Java (server side) and JavaScript (client). Commands can be execute on multiple terminals simultaneously running on OpenShift. Two-factor authentication using one-time passwords. Licensed under the Apache License version 2.0.

Mist.io is written in Python (server side) and JavaScript (client). It uses the term.js library and provides a touch-friendly console and key management through the web. Licensed under the AGPL version 3.0.

References

External links

Software for installation:

Hosted solutions:

Commando.io: A free and paid plans.
consoleFISH at serFISH.com: Free for short sessions.
myconsole.org: Free shell, no connection or server limit.