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)
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.
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 always \
--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.
The following tools are required in order to compile the software from source code:
git
to download the source codenode
andnpm
to build front-end applicationgo
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.
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
.
Here is all the options of the configuration file:
sshwifty.conf.example.json
is an example of a valid configuration file, you
can make your own customization base on it.
Valid environment variables are:
SSHWIFTY_HOSTNAME
SSHWIFTY_SHAREDKEY
SSHWIFTY_DIALTIMEOUT
SSHWIFTY_SOCKS5
SSHWIFTY_SOCKS5_USER
SSHWIFTY_SOCKS5_PASSWORD
SSHWIFTY_LISTENPORT
SSHWIFTY_INITIALTIMEOUT
SSHWIFTY_READTIMEOUT
SSHWIFTY_WRITETIMEOUT
SSHWIFTY_HEARTBEATTIMEOUT
SSHWIFTY_READDELAY
SSHWIFTY_WRITEELAY
SSHWIFTY_LISTENINTERFACE
SSHWIFTY_TLSCERTIFICATEFILE
SSHWIFTY_TLSCERTIFICATEKEYFILE
SSHWIFTY_SERVERMESSAGE
SSHWIFTY_PRESETS
SSHWIFTY_ONLYALLOWPRESETREMOTES
These options are correspond to their counterparts in the configuration file.
Notice: When you're using environment variables to configure Sshwifty, only one Sshwifty HTTP server is then allowed. There is no way to setup multiple servers under this method of configuration. If you need to serve on multiple ports, use the configuration file instead.
Be aware: An invalid value inside following environment variables will cause the value to be silently reset to default during configuration parsing phase without warning:
SSHWIFTY_DIALTIMEOUT
SSHWIFTY_INITIALTIMEOUT
SSHWIFTY_READTIMEOUT
SSHWIFTY_WRITETIMEOUT
SSHWIFTY_HEARTBEATTIMEOUT
SSHWIFTY_READDELAY
SSHWIFTY_WRITEELAY
Please verify the value of these options before start the instance.
Currently, Sshwifty implemented a layer of obscuration in it's wire protocol. The protocol utilize the common time of both endpoint to generate cryptographic keys to be used to encrypt and decrypt traffic between the client and the server. Thus both end must have accurate datetime relative to the time of the world.
Please make sure the datetime on both the client and the server are correct by resync them with a NTP server, and then simply reload the page. The problem should be gone afterwards.
Sshwifty's wire protocol requires few cryptographic features which is only available with WebCrypt API. Some old web browsers maybe not support WebCrypt API, or the newer ones may disable WebCrypt API when the web page is not accessed under Secure contexts, which led to the error message.
Usually, setup HTTPS either on your reverse proxy or on Sshwifty itself should
allow you to access Sshwifty via HTTPS (a https://
URL), and thus solving this
issue. Also, enabling HTTPS is mostly a good idea anyways, even in a LAN.
The short story is No. Sshwifty was designed based on an assumption that it will run as the only service under a given hostname, allowing web browsers to better enforce their data isolation rules. This is very important because Sshwifty saves user data locally, right on the web browser.
However, if you really want to put Sshwifty into a subpath, you can do so by
taking advantage of the fact that Sshwifty backend interface and assets are
always located under an URL prefix /sshwifty
. You can thus redirect or proxy
those requests to their new location.
Keep in mind, doing so is really hacky, and it's not recommended by the author thus no support will be provided if you decide to do so.
The pre-defined key combinations are there mainly to make mobile operation possible as well as to resolve some hotkey conflicts. However, if efficiency is your first goal, please consider to use a software/on screen keyboard which is specially designed for terminal.
And if that's not enough, connect a physical keyboard through Bluetooth or OTA could be a better alternative. This way you can type as if you're using a computer console.
- Thanks to Ryan Fortner for the grammar fix
- Thanks to Tweak for the grammar fix
- Thanks to CJendantix for the grammar and typo fix
- Thanks to ZStrikeGit for the grammar and formatting fixes
Code of this project is licensed under AGPL, see LICENSE.md for detail.
Third-party components used by this project are licensed under their respective licenses. See DEPENDENCIES.md to learn more about dependencies used by this project and read their copyright statements.
This is a hobbyist project, meaning I don't have that much time to put into it, sorry.
Upon release (Which is then you're able to read this file), this project will enter the maintaining state, which includes doing some bug fixes and security updates. Adding new features however, is not a part of the state.
Please do not send any pull requests. If you need new feature, fork it, add it by yourself, then maintain it like one of your own project. It's not that hard with some Github features.
(Notice: Typos, grammar errors or invalid use of language in the source code and documentation should be categorized as a bug, please report them if you find any. Thank you!)
Appreciate your help, enjoy!