cccb-website-team/kik-website
Watch
0
0
Fork
You've already forked kik-website
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Restore the SSH access in the cleanup

Browse source 
The key that the website logs in with lives in the home directory of the
user, so a deleted home directory took it away and the site could not
connect any more. The key is now one of the copies the cleanup restores,
and it is merged into the authorized_keys of the user, so that keys they
added stay.

The installer writes the same key for the Administrator, and the deploy
script checks that it is the key the website uses.

Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
Zebreus 2026-10-25 13:35:05 +01:00
commit 22106dcd7d
1 changed files with 106 additions and 28 deletions
Download patch file Download diff file Expand all files Collapse all files

26
server/README.md
View file

@ -21,9 +21,14 @@ We only keep the basic user journey working.
which the user cannot change, because `/etc` is read-only for them. They can delete their home directory, though.
- `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.
- The website can log in: the key it uses is in `~/.ssh/authorized_keys`.
Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not permanent either.
The user may add keys of their own to `authorized_keys`; they stay. The key of the website is put back, so that the
site keeps working. The user owns their home directory, so they can always delete the file - nothing on Windows can
stop them from that - but the next cleanup brings it back. Until then, the site cannot log in.
## What we do not keep working
Everything else. If the user breaks the shell, the packages, the disk or the connection, we fix that by hand or
@ -46,7 +51,8 @@ different one, without administrator rights, and it never executes any of it.
What the cleanup does:
1. Creates `/home/root` if it is gone, and gives the `root` account write access on it.
2. Puts every copy in `files/` back into the home directory: the shell configuration and the four text files.
2. Puts every copy in `files/` back into the home directory: the shell configuration, the keys and the four text
files.
Anything that is not a regular file - a directory or a link - is removed and replaced by the copy, so that the
files cannot become anything but text. The contents are restored as well: the user may edit the files, the next run
@ -54,13 +60,15 @@ undoes that.
## This directory
- `shell/` - the shell configuration, `~/.zshrc` and `~/.zshenv`, which is where the prompt is set.
- `resources/` - the copies the cleanup restores from: the shell configuration and the four text files.
- `home/` - the files that belong in the home directory of the user: `~/.zshrc`, `~/.zshenv` and the key in
`~/.ssh/authorized_keys` that the website logs in with. This is where they are edited.
- `resources/` - the copies the cleanup restores from: the four text files and the files of `home/`.
- `scripts/make_files.py` - builds the resources.
- `scripts/deploy.sh` - deploys the cleanup to the server and installs it.
- `scripts/install_restore_task.ps1` - installs the scheduled task.
- `scripts/restore_ssh_access.cmd` - puts the SSH access back, for when the home directory was deleted.
The resources are built from the website's pages and the shell configuration:
The resources are built from the website's pages and the files of `home/`:
python3 server/scripts/make_files.py
@ -70,8 +78,8 @@ The resources are built from the website's pages and the shell configuration:
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. It uses the key the website uses, which is authorized
for the Administrator account as well, and checks the host key against the one the website pins. `--uninstall`
removes the task again.
for the Administrator account as well, checks the host key against the one the website pins, and checks that the key
in `home/.ssh/authorized_keys` is the one the website uses. `--uninstall` removes the task again.
The installer can also be run by hand, in an elevated PowerShell on the server:
@ -79,3 +87,9 @@ The installer can also be run by hand, in an elevated PowerShell on the server:
The task runs as SYSTEM, so the `root` user can neither stop it nor change the copies it restores from. It also
runs at startup. Remove it again with `-Uninstall`.
## Getting the SSH access back
If the home directory was deleted, the key that lets the website in went with it, and so did the Administrator's.
Over RDP, as Administrator, run `scripts/restore_ssh_access.cmd`. From then on the cleanup puts the key back by
itself.