Sshwifty Web SSH & Telnet Client

Sshwifty is a SSH and Telnet client made for the Web, allow you to access SSH and Telnet services right from your web browser.

(The glass glare effect above is only included in the Executive Golden Premium Plus+ Platinum Ultimate AD-free version, which can be obtained after joining the cult. Though, science has proven that the normal AD-free version is sufficient for most people. In fact, the majority of people surveyed are annoyed by the glare, while the rest showed a little interest)

Install

Prebuilt Executables

We offer prebuilt ready-to-run programs (called executables) for a handful of popular platforms in the Releases section. You might find one built for your platform there.

Please aware that these executables are generated by an unsupervised automatic procedure, and we (as the authors and contributors) cannot guarantee to test them. If you've encountered unusual failure caused by those executables, feel free to open an issue, so we can take a look.

Docker Image (recommended)

Deploying Sshwifty as a Docker container allows you to isolate Sshwifty from the rest of the system for better system organization and security.

We also offer prebuilt Docker Images for few selected platforms generated in the same way as we generate the prebuilt Executables described above. To deploy one on your Docker host, run:

$ docker run --detach \
  --restart unless-stopped \
  --publish 8182:8182 \
  --name sshwifty \
  niruix/sshwifty:latest

(Note: it's niruix/sshwifty with an x)

This will open port 8182 on the Docker host to accept traffic from all clients (including remote ones), and serve them with the Sshwifty instance just created.

To expose Sshwifty locally only to the Docker host, change the line --publish 8182:8182 from the command above to --publish 127.0.0.1:8182:8182. This is useful for scenarios where you want to force remote clients to access Sshwifty only though a reverse proxy, or just simply want to prevent remote access.

When TLS is desired and you don't want to setup Docker Volumes, you can use SSHWIFTY_DOCKER_TLSCERT and SSHWIFTY_DOCKER_TLSCERTKEY environment variables to import certificate files to the container and automatically apply them:

$ openssl req \
  -newkey rsa:4096 -nodes -keyout domain.key -x509 -days 90 -out domain.crt
$ docker run --detach \
  --restart always \
  --publish 8182:8182 \
  --env SSHWIFTY_DOCKER_TLSCERT="$(cat domain.crt)" \
  --env SSHWIFTY_DOCKER_TLSCERTKEY="$(cat domain.key)" \
  --name sshwifty \
  niruix/sshwifty:latest

The domain.crt and domain.key in the command above is the location of valid X509 certificate and key file.

Though, in most situations where a reverse proxy and/or load balancer (for example, Nginx or Traefik) is used in front of Sshwifty instances, TLS should usually terminate on the proxy, not on the individual Sshwifty instances.

Compile from source code (recommended for developers)

The following tools are required in order to compile the software from source code:

• git to download the source code
• node and npm to build front-end application
• go to build back-end application

To start the build process, run:

$ git clone https://github.com/nirui/sshwifty
$ cd sshwifty
$ npm install
$ npm run build

When done, you can find the newly generated sshwifty binary under current working directory.

Notice: Dockerfile contains the entire build procedure of this software. Please refer to it when you encounter any compile/build related issue.

Third-party Homebrew Formulae from @unbeatable-101

If you're a macOS user, @unbeatable-101 is kindly hosting a Homebrew Formulae that allows you to install his custom Sshwifty builds for macOS via homebrew. You can hop over to unbeatable-101/homebrew-sshwifty for detailed instruction and contribute to his work.

Please note that, due to the third-party nature of the work, the author(s) of Sshwifty are unable to provide any audit, warranty or support for it. If you have any question or request regarding to the Formulae, please contact @unbeatable-101 directly through appreciate channels.

Thank @unbeatable-101 for his work.

Configuration

Sshwifty can be configured through either file or environment variables. By default, the configuration loader will try to load file from default paths first, when all failed, environment variables will be used.

You can also specify your own configuration file with SSHWIFTY_CONFIG environment variable. For example:

$ SSHWIFTY_CONFIG=./sshwifty.conf.json ./sshwifty

This tells Sshwifty to only load configuration from file ./sshwifty.conf.json.

Configuration file option and descriptions

Here is all the options of the configuration file:

{
  // HTTP Host. Keep it empty to accept request from all hosts, otherwise, only
  // specified host is allowed to access
  "HostName": "localhost",

  // Web interface access password. Set to empty to allow public access to the
  // web interface (By pass the Authenticate page)
  "SharedKey": "WEB_ACCESS_PASSWORD",

  // Remote dial timeout. This limits how long of time the backend can spend
  // to connect to a remote host. The max timeout will be determined by
  // server configuration (ReadTimeout).
  // (In Seconds)
  "DialTimeout": 10,

  // Socks5 proxy. When set, Sshwifty backend will try to connect remote through
  // the given proxy
  "Socks5": "localhost:1080",

  // Username of the Socks5 server. Please set when needed
  "Socks5User": "",

  // Password of the Socks5 server. Please set when needed
  "Socks5Password": "",

  // Server side hooks, allowing operator to launch external processes on the
  // server side to influence server behaver
  //
  // The operation of a Hook must be completed within the time limit defined
  // by `HookTimeout` set below. Otherwise it will be terminated, and results
  // a failure for the execution
  //
  // To determine how much time is still left for the execution, a Hook can
  // fetch the deadline information from the `SSHWIFTY_HOOK_DEADLINE`
  // environment variable which is a RFC3339 formatted date string indicating
  // after what time the termination will occur
  //
  // Warning: the process will be launched within the same context and system
  // permission which Sshwifty is running under, thus is it crucial that the
  // Hook process is designed and operated in a secure manner, otherwise
  // SECURITY VULNERABILITY (commandline injection, for example) maybe created
  // as result
  //
  // Warning: all inputs passed by Sshwifty to the hook process must be
  // considered unsanitized, and must be sanitized by each hook themselves
  "Hooks": {
    // before_connecting is called before Sshwifty starts to connect to a remote
    // endpoint. If any of the Hook process exited with a non-zero return code,
    // the connection request is aborted
    //
    // This Hook offers two parameters:
    // - SSHWIFTY_HOOK_REMOTE_TYPE: Type of the connection (i.e. SSH or Telnet)
    // - SSHWIFTY_HOOK_REMOTE_ADDRESS: Address of the remote host
    "before_connecting": [
      // Following example command launches a `/bin/sh` to execute a for loop
      // that prints to Stdout as well as to Stderr
      //
      // Prints to Stdout will be sent to the client side visible to the user,
      // and prints to Stderr will be captured as server side logs and it is
      // invisible to the user (as server logs usually are)
      //
      // The command must be specified in Json array format. Each array element
      // is mapped to a command fragment separated by space. For example:
      // ["command", "-i", "Hello World"] will be mapped to `command -i "Hello
      // World"` before it is executed
      [
        "/bin/sh",
        "-c",
        "for n in $(seq 1 5); do sleep 1 && echo Stdout $SSHWIFTY_HOOK_REMOTE_TYPE $n && echo Stderr $SSHWIFTY_HOOK_REMOTE_TYPE $n 1>&2; done"
      ],
      // You can add multiple hooks, they're executed in sequence even when the
      // previous one fails
      [
        "/bin/sh",
        "-c",
        "/etc/sshwifty/before_connecting.sh"
      ],
      [
        "/bin/another-command",
        "...",
        "..."
      ]
    ]
  },

  // The maximum execution time of each hook, in seconds. If this timeout is 
  // exceeded, the hook will be terminated, and thus cause a failure
  "HookTimeout": 30,

  // Sshwifty HTTP server, you can set multiple ones to serve on different
  // ports
  "Servers": [
    {
      // Which local network interface this server will be listening
      "ListenInterface": "0.0.0.0",

      // Which local network port this server will be listening
      "ListenPort": 8182,

      // Timeout of initial request. HTTP handshake must be finished within
      // this time
      // (In Seconds)
      "InitialTimeout": 10,

      // How long do the connection can stay in idle before the backend server
      // disconnects the client
      // (In Seconds)
      "ReadTimeout": 120,

      // How long the server will wait until the client connection is ready to
      // recieve new data. If this timeout is exceed, the connection will be
      // closed.
      // (In Seconds)
      "WriteTimeout": 120,

      // The interval between internal echo requests
      // (In Seconds)
      "HeartbeatTimeout": 10,

      // Forced delay between each request
      // (In Milliseconds)
      "ReadDelay": 10,

      // Forced delay between each write