Authentication
How you prove who you are to rickub — in the browser, over git, and from scripts.
Sessions
Signing in on the website creates a secure session cookie. That session is what authorizes you in the UI; it doesn't work for git or the API, which use tokens and keys instead.
Personal access tokens
A personal access token (PAT) authenticates git over HTTPS and every API and CLI request. Create one under Settings → Access tokens, copy it immediately (it's shown only once), and use it as the password when git prompts, or as a bearer token for the API. Every rickub token starts with rickub_pat_.
Use the token as the password (with your handle as the username) — that's the recommended setup. For tools with GitHub-style muscle memory, rickub also accepts the token in the username field with an empty password.
Each token has one of two access levels: Full access — clone, push, and mutate through the API and MCP — or Read-only, which can clone and fetch and make read-only API/MCP calls but can never push or change anything. Pick the narrowest level a task needs.
A token is shown once, at creation. Store it safely — if you lose it, delete it and create a new one. Revoke tokens you no longer use.
SSH keys
To use git over SSH, register your public key under Settings → SSH keys. Generate a key if you don't have one, then add the .pub file's contents:
ssh-keygen -t ed25519 -C "you@example.com"
cat ~/.ssh/id_ed25519.pub # paste this into Settings → SSH keysTwo-factor authentication
Add a second factor to your sign-in from Settings → Two-factor auth. It uses a standard authenticator app (TOTP); once it's on, signing in on the website asks for a one-time code — or a recovery code — in addition to your password.
SSO for organizations
Organizations on a plan that includes it can require single sign-on. rickub uses OpenID Connect (OIDC): members authenticate through the organization's identity provider before accessing its repositories. Owners configure SSO from the organization's Security settings.