# What is webtech-admin
`webtech-admin` and its client counterpart `webtech-ssh` together form the authentication system for webtech. In previous years, there have been various ways of getting login credentials to students; we used to have password authentication, with passwords available on a site requiring UvAnetid login, and we had a year where we had students submit SSH keys. Passwords are, of course, not ideal, and having students submit SSH keys is asking for trouble (getting submissions of key fingerprints, private keys, keys generated for the wrong system, etc, etc) and still required a bunch of manual labor to get the keys onto the servers.

Webtech-admin attempts to achieve both best practices (SSH key login, password login disabled) and minimal effort, and it achieves this through SSH certificates.
SSH certificates are, as the name implies, not dissimilar from SSL certificates. A server trusts some certificate authority, which hands out certificates, and anyone trying to login needs to present a valid certificate along with their SSH key.
A similar system also exists for host key verification; a user trusts a certificate authority, and hosts can present a certificate stating they are indeed the host you think they are.
`webtech-admin` fulfills the role of certificate authority here. It signs host and user keys, yielding certificates, which are then used for authentication later.

In order to do so, `webtech-admin` needs to have a way of verifying server and user identity. For servers, we use an IP whitelist; this is easy. For users, we use SURFconext login, which provides us with an UvAnetid that we can match to a database which contains information about the student, specifically their username on their server. We can then sign their user key, yielding a certificate which is valid for that username, and they can then log into any server which has such a user and trusts the `webtech-admin` user CA. This means "getting the keys onto the servers" is reduced to "getting the servers to trust the user CA" and "getting the servers to sign their host keys", which are trivial in an Ansible play. Of course, the user now has a whole workflow to get their keys signed.

This is where `webtech-ssh` comes in. A little self-contained tool, written in Rust, provided as a static binary, which generates an SSH key, asks the user to log in to the webtech-admin server, signs the SSH key, trusts the host CA, and adds a `Match` block to `~/.ssh/config` which automatically uses the key when connecting to a `*.webtech-uva.nl` server. Users now only need to run `curl https://webtech-admin.datanose.nl/static/webtech-ssh.sh | sh -`, and after logging in in their browser and waiting for a few seconds, they can SSH into their server with no further setup.

# What do I have to do?
From memory, at least these steps:
- [ ] Make sure `webtech-admin` is running, and probably clear the DB from last year
- [ ] Make sure the latest version of `webtech-ssh` is available from `webtech-admin.datanose.nl/static/` (if you haven't made any changes, it will be)
- [ ] Make sure the server IPs are in the `webtech-admin` DB (table `host_ranges`)
- [ ] Make sure the student group data is in the `webtech-admin` DB (see `webtech-admin/update_db.py`)