This is an A to Z guide that will help you get `wetty` up and running on Debian Stable. It covers the key configuration areas by using copy and paste commands to help you install this application and get it securely up and running. It should also provide enough information to allow you to understand and extend that configuration for your personal requirements.
This is an A to Z guide that will help you get `wetty` up and running on Debian
Stable. It covers the key configuration areas by using copy and paste commands
to help you install this application and get it securely up and running. It
should also provide enough information to allow you to understand and extend
that configuration for your personal requirements.
### Required dependencies
You will need the package `build-essential` to be installed. We need this specifically for `node-gyp` to build packages when using `npm` or `yarn` to install packages.
You will need the package `build-essential` to be installed. We need this
specifically for `node-gyp` to build packages when using `npm` or `yarn` to
install packages.
As the `root` user run these commands:
@ -13,7 +19,8 @@ apt update
apt install -y build-essential
```
If you do not have root access and just want to check the dependency is installed you can use this command:
If you do not have root access and just want to check the dependency is
installed you can use this command:
```bash
dpkg -s build-essential | grep Status:
@ -27,23 +34,32 @@ Status: install ok installed
### Create a local user account
For this guide, unless specifically stated, you should not use a `root` account to install and run `wetty`. Please use an existing local account or create one now.
For this guide, unless specifically stated, you should not use a `root` account
to install and run `wetty`. Please use an existing local account or create one
now.
**Note:** Whichever user runs `wetty` should be the same user you wish to authenticate with via `ssh` to keep this simple.
**Note:** Whichever user runs `wetty` should be the same user you wish to
authenticate with via `ssh` to keep this simple.
If you need to create a local user account you can run this command:
**Important note:** replace `username` with a user name of your choosing and create a password when prompted
**Important note:** replace `username` with a user name of your choosing and
create a password when prompted
```bash
adduser --gecos "" username
```
Switch to your local user now and open an `ssh` session to continue with this guide.
Switch to your local user now and open an `ssh` session to continue with this
guide.
### Install node locally
To install and manage `node` as a local user we are going to use [Node Version Manager](https://github.com/nvm-sh/nvm) as an established solution to installing and managing multiple versions of node without needing `root` access. We are going to install the `lts` or long term support release of `node` to use with this application.
To install and manage `node` as a local user we are going to use
[Node Version Manager](https://github.com/nvm-sh/nvm) as an established solution
to installing and managing multiple versions of node without needing `root`
access. We are going to install the `lts` or long term support release of `node`
@ -62,19 +78,26 @@ Your result should look something like this.
v12.16.2
```
**Note:** There is consideration with this method. `node` is only in the local user's path through sourcing of the `~/.nvm/nvm.sh` via the users `.bashrc` file. Unless this is done `node` will not be usable unless directly linked to and `nvm` commands will be unavailable.
**Note:** There is consideration with this method. `node` is only in the local
user's path through sourcing of the `~/.nvm/nvm.sh` via the users `.bashrc`
file. Unless this is done `node` will not be usable unless directly linked to
and `nvm` commands will be unavailable.
The way we over come this issue for the needs of this guide is by using this command where applicable:
The way we over come this issue for the needs of this guide is by using this
command where applicable:
```bash
source ~/.nvm/nvm.sh && nvm which 12
source ~/.nvm/nvm.sh && nvm which 14
```
**Why?** This command will always provide us with the path to the most current version of `node 12` installed via `nvm` regardless of other versions of `node` installed.
**Why?** This command will always provide us with the path to the most current
version of `node 12` installed via `nvm` regardless of other versions of `node`
installed.
### Generate openssl certificates.
**Why?** So that later we can configure `wetty` to work with `https` and make sure we interact with `wetty` over a secure connection at all times.
**Why?** So that later we can configure `wetty` to work with `https` and make
sure we interact with `wetty` over a secure connection at all times.
Make the required directory using this command:
@ -82,7 +105,8 @@ Make the required directory using this command:
mkdir -p ~/.ssl
```
Generate the self signed `openssl` certificates we will use to encrypt our web traffic when using `wetty` using this command:
Generate the self signed `openssl` certificates we will use to encrypt our web
traffic when using `wetty` using this command:
**Note:** we are using`ecdsa` using the `secp521r1` curve.
@ -102,7 +126,8 @@ This is all we need to do for now in regards to https.
### Generate the ssh key file
**Why?** So that later we can set up automatic login via `ssh`. Our instance will authorise using this key file stored locally.
**Why?** So that later we can set up automatic login via `ssh`. Our instance
will authorise using this key file stored locally.
Make the required directory, if it does not exist, using this command:
@ -110,13 +135,16 @@ Make the required directory, if it does not exist, using this command:
mkdir -p ~/.ssh
```
Create the `ssh` private key using `ed25519` that we need to authorise our local connection, using this command:
Create the `ssh` private key using `ed25519` that we need to authorise our local
**Important Note:** You must add the public key to your `authorized_keys` file in order to be able to log in using your `ssh` key file when accessing `wetty` via a web browser.
**Important Note:** You must add the public key to your `authorized_keys` file
in order to be able to log in using your `ssh` key file when accessing `wetty`
via a web browser.
Copy the key to our `~/.ssh/authorized_keys` file, using this command:
**Optional:** A housekeeping command. If you need to remove all entries of the `wetty` public key with the comment `wetty-keyfile` from the `~/.ssh/authorized_keys` file use this command. Otherwise ignore this.
**Optional:** A housekeeping command. If you need to remove all entries of the
`wetty` public key with the comment `wetty-keyfile` from the
`~/.ssh/authorized_keys` file use this command. Otherwise ignore this.
```bash
sed -r '/^ssh-ed25519(.*)wetty-keyfile$/d' -i ~/.ssh/authorized_keys
@ -140,17 +170,23 @@ sed -r '/^ssh-ed25519(.*)wetty-keyfile$/d' -i ~/.ssh/authorized_keys
### Install wetty
**Note:** we are using `-g` for `npm` or `global` for `yarn` along with `--prefix ~/` so that the application symbolic link is installed to our `~/bin` directory and available in our local user's `PATH`.
**Note:** we are using `-g` for `npm` or `global` for `yarn` along with
`--prefix ~/` so that the application symbolic link is installed to our `~/bin`
directory and available in our local user's `PATH`.
As your local user run these commands to install `wetty` and `forever`. We will need `forever` later to run wetty in the background.
As your local user run these commands to install `wetty` and `forever`. We will
need `forever` later to run wetty in the background.
First, we need to make sure the local user's `~/bin` folder exists and is in the `PATH` for the following commands to work.
First, we need to make sure the local user's `~/bin` folder exists and is in the
`PATH` for the following commands to work.
```bash
mkdir -p ~/bin && source ~/.profile
```
Please use either the `npm` or `yarn` method and not both. The `yarn` method is recommended but I provide both as you may have a personal preference. The outcome is effectively the same.
Please use either the `npm` or `yarn` method and not both. The `yarn` method is
recommended but I provide both as you may have a personal preference. The
Once successfully installed the application should be available in your local user's `PATH`. To test the installation was successful please use this command:
Once successfully installed the application should be available in your local
user's `PATH`. To test the installation was successful please use this command:
```bash
wetty -h
@ -173,23 +210,29 @@ wetty -h
### Accessing the web interface.
This needs to be done here because it is not easy to do in the next steps if `wetty` is running in the terminal.
This needs to be done here because it is not easy to do in the next steps if
`wetty` is running in the terminal.
This command will generate the correct URL you need to visit after using the start up commands in the following section.
This command will generate the correct URL you need to visit after using the
start up commands in the following section.
```bash
echo https://$(curl -s4 icanhazip.com):3000
```
*Please make make a note of this URL now.*
_Please make make a note of this URL now._
### Running wetty
Now we have all the ground work done we can focus on our `wetty` server configuration settings.
Now we have all the ground work done we can focus on our `wetty` server
configuration settings.
For example, the below command would provide a `https` instance with automatic `ssh` authorisation using our `wetty` private key on port `3000` accessible at `https://IP:3000` . Refer to the previous URL generation command.
For example, the below command would provide a `https` instance with automatic
`ssh` authorisation using our `wetty` private key on port `3000` accessible at
`https://IP:3000` . Refer to the previous URL generation command.
**Important note:** This command will run in your current terminal session and not in the background.
**Important note:** This command will run in your current terminal session and
**Important Note:** This is an optional and unsupported method to load settings from a physical configuration file. It's a hack and you need to accept it has some limitations but I've made it as easy as I can to use.
Since `wetty` does not have configurations files and all commands are passed as command line arguments we can fake this behaviour by using a method to read from a text file and expand variables then pass this to `wetty`. All arguments must be on a single line
Create a directory to store our configuration data using this command:
```bash
mkdir -p ~/.config/wetty
```
Now populate our `config` file with some settings. This examples is the same command as above.
Now populate our `config` file with some settings. This examples is the same
To stop `wetty` from running you can use this command:
@ -261,43 +304,63 @@ Let's break it down so that we can understand what's being done and why.
--host 0.0.0.0 -p 3000 --title wetty --base /
```
`--host 0.0.0.0` - defines the interface we want to bind to. Using `0.0.0.0` means that we bind to all available interfaces so using this setting just works. When we use nginx we can change this to `--host 127.0.0.1` in order to prevent generic port access to the application and force traffic through our nginx reverse proxy URL.
`--host 0.0.0.0` - defines the interface we want to bind to. Using `0.0.0.0`
means that we bind to all available interfaces so using this setting just works.
When we use nginx we can change this to `--host 127.0.0.1` in order to prevent
generic port access to the application and force traffic through our nginx
reverse proxy URL.
`-p 3000` - defines the local listening port. You will use this port to connect via the remotely accessible web server or when configuring a reverse proxy through nginx.
`-p 3000` - defines the local listening port. You will use this port to connect
via the remotely accessible web server or when configuring a reverse proxy
through nginx.
`--title wetty` - an optional setting to set the window title for this `wetty` session.
`--title wetty` - an optional setting to set the window title for this `wetty`
session.
`--base /` - changes the default base URL setting from `/wetty/` to define the remote URL. We use `--base /` to make `wetty` accessible on the URL format `https://IP:3000` instead of `https://IP:3000/wetty` but we would change this back if we use nginx to reverse proxy the application.
`--base /` - changes the default base URL setting from `/wetty/` to define the
remote URL. We use `--base /` to make `wetty` accessible on the URL format
`https://IP:3000` instead of `https://IP:3000/wetty` but we would change this
back if we use nginx to reverse proxy the application.
#### SSH settings explained
These settings are all specific to `ssh` and will enable you to automatically log into you ssh session for the selected user.
These settings are all specific to `ssh` and will enable you to automatically
`--sshkey ~/.ssh/wetty` - we are telling `wetty` to load our `ssh` key file that we generated earlier.
`--ssh-key ~/.ssh/wetty` - we are telling `wetty` to load our `ssh` key file
that we generated earlier.
`--sshhost localhost` - optional setting telling `wetty` to connect the host `localhost`
`--ssh-host localhost` - optional setting telling `wetty` to connect the host
`localhost`
`--sshuser $(whomai)` - defines our `ssh` username. In this case via the command substitution of `whoami` which will not require your input of a username.
`--ssh-user $(whomai)` - defines our `ssh` username. In this case via the
command substitution of `whoami` which will not require your input of a
username.
`--sshport 22` - optional setting to set the `ssh` port we need to connect to.
`--ssh-port 22` - optional setting to set the `ssh` port we need to connect to.
`--sshauth publickey` defines the accepted authentication types. You do not have to use the key file and you can instead require a password but setting this to `--sshauth password`. You can specify both `--sshauth publickey,password`
`--ssh-auth publickey` defines the accepted authentication types. You do not
have to use the key file and you can instead require a password but setting this
to `--ssh-auth password`. You can specify both `--ssh-auth publickey,password`
#### SSL settings explained
These settings are specific to `openssl` to make `wetty` load https webserver so that all data is transmitted over a secure connection.
These settings are specific to `openssl` to make `wetty` load https webserver so
that all data is transmitted over a secure connection.
Press `ctrl` + `x` and then press `y` to save then press `enter` to confirm and exit `nano`.
#### Optional - Systemd service with config file
Here is the example using our pseudo configuration file. All modifications to the start up of `wetty` will be done by editing the `~/.config/Wetty/config` file and then reloading the ` wetty.service`.
butlerx
4 years ago