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

Keep the key of the website away from the Administrator account

Browse source 
The key that the website logs in with was written into the authorized_keys
of the Administrator, which would have given everyone who has the website
administrator rights on the box. It only gets access as the root user.

The deploy script logs in as Administrator with the personal key of the
deployer instead, from the agent or from -i.

Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
Zebreus 2026-10-25 13:50:40 +01:00
commit fc7b75b930
1 changed files with 30 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

15
server/README.md
View file

@ -21,7 +21,8 @@ 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`.
- The website can log in: the key it uses is in `~/.ssh/authorized_keys`. That key gets access to the `root` user
only, never to the Administrator account, whose keys belong to the people who deploy.
Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not permanent either.
@ -77,9 +78,10 @@ The resources are built from the website's pages and the files of `home/`:
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. It uses the key the website uses, which is authorized
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.
Administrator's home directory and runs the installer there. It logs in with the personal key of the deployer, from
the agent or from `-i`; the key of the website never gets administrator rights, it only logs in as the root user.
It 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:
@ -90,6 +92,5 @@ 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.
If the home directory was deleted, the key that lets the website in went with it. Over RDP, as Administrator, run
`scripts/restore_ssh_access.cmd`. From then on the cleanup puts the key back by itself.