# The shell server

The website's terminal connects to a shell server, whose `root` user logs in at `wss://web.nowhere.wirs.ing` and
gets a shell on the box.

## The security model

The box is an isolated, disposable VPS at a random hoster. We assume that it can be compromised and that this is
acceptable: the worst case is that the gimmick on the website stops working. Nothing else is on the box. The
website and the websocket bridge that carries the connection run on other servers, so a compromised shell server
cannot get at them.

The `root` user on the box is a normal Windows account without administrator rights. It may do a lot of things
there, including things we did not plan for. We do not try to contain it and we do not try to undo what it does.
We only keep the basic user journey working.

## What we keep working

Anything that breaks the following user journey is not acceptable:

- The user can connect with the SSH key as `root`.
- The prompt: `root@khaos-im-kiez:~#`, which `~/.zshrc` sets.
- The home directory the user ends up in: `/home/root`. They cannot change where it is, and they cannot delete it.
- `cat README`, `cat README.en`, `cat CODE_OF_CONDUCT` and `cat CODE_OF_CONDUCT.en` always work. The four files
  are always there and always regular text files.

So in summary running `ssh root@nowhere.wirs.ing cat README` must always succeed and display the contents of the file.

Anything thats not specified above (like the content of README for example) is NOT part of the user journey.

## What we do not keep working

As long as the user story above does not break, we do not guarantee the functionality of anything else on the server. However the cleanup task should still try to best-effort restore everything to a working condition.

## The cleanup task

The scheduled task `KiK restore shell files` runs every 30 minutes and at every startup, as SYSTEM. The user cannot stop it. Cleanup has two jobs:

1. Act as a secondary safeguard to restore the essential files for the user journey above.
2. Revert any other mockery the user did that might affect the system.

The second job should also be able to restore a new server to the expected state.

## Installing the cleanup on the server

To deploy the cleanup task an the server, run:

    server/scripts/deploy.sh

The script logs in as `Administrator` - whose shell is a Windows one - copies the scripts and the resources to the
Administrator's home directory and runs the installer there.