Your account settings
Your personal settings live under your avatar → Settings (frem.sh/user/settings). These are your account, separate from any org’s admin surface — they travel with you across every org you belong to. This page covers the self-service surfaces you manage yourself: keys, tokens, and notifications.
SSH keys
If your org allows SSH (it’s disabled by default on new orgs — see When SSH isn’t permitted below), you register your public keys here.
To add a key: open Settings → SSH / GPG keys, paste your public key (the contents of ~/.ssh/id_ed25519.pub), give it a recognisable name, and save. fremforge shows the key’s fingerprint and the date it was last used to authenticate, so you can spot a key you no longer recognise.
To revoke a key: delete it from the same page. Revocation is immediate — the next Git operation using that key is refused. Revoke any key on a lost or decommissioned device straight away.
Prefer hardware-backed keys (sk-* algorithms — Touch ID, FIDO/YubiKey). Some orgs require them, in which case a non-hardware key is rejected at registration. See Secure sign-in for the full key-generation walkthrough.
GPG keys
Register a GPG public key here to have your signed commits and tags show as Verified in the UI.
To add a key: open Settings → SSH / GPG keys, paste your ASCII-armored public key (gpg --armor --export <key-id>), and save. fremforge verifies that the key’s email matches a verified email on your account before it will mark commits verified.
To revoke a key: delete it from the same page. Existing commits already signed with it keep their historical signature; new commits signed with the deleted key stop showing as verified.
If you’d rather not manage long-lived signing keys at all, fremforge supports keyless, identity-based commit signing through your IdP — no key to generate, store, or rotate. See Keyless commit signing.
Personal access tokens (PATs)
A personal access token authenticates Git operations and API calls as you, without an interactive browser sign-in — handy for scripts, local tooling, and any client that can’t run the GCM browser flow.
To create a token: open Settings → Applications → Personal access tokens, give it a descriptive name, choose its scopes (grant only what the use case needs), set an expiry, and generate. The token value is shown once — copy it immediately; you can’t retrieve it later.
Use a PAT as the password for HTTPS Git operations, or as a bearer token for the REST API:
# Git over HTTPS
git clone https://frem.sh/<org>/<repo>.git
# username: your fremforge username; password: the PAT
# REST API
curl -H "Authorization: token <PAT>" https://frem.sh/api/v1/userTo revoke a token: delete it from the same page. Revocation is immediate. Revoke any token that may have leaked, and prefer short expiries so a forgotten token ages out on its own. Your org may cap the maximum token lifetime; if your chosen expiry is rejected, that cap is why.
For day-to-day human Git use, interactive HTTPS + Git Credential Manager (with MFA on every refresh) is the recommended path over a long-lived PAT. See Secure sign-in.
Notification preferences
Open Settings → Notifications to control how fremforge reaches you — the email notification toggle governs whether you receive email for events you’re subscribed to (issues and PRs you’re assigned to, mentions, reviews requested of you, and repositories you watch). Turn it off to rely on the in-app notification inbox alone, or leave it on to get email as well. Per-repository watch settings (the Watch control on each repo) decide which repositories feed into these notifications in the first place.
When SSH isn’t permitted
New orgs ship with SSH sign-in disabled — HTTPS is the default Git path. If every org you belong to has SSH disabled, the SSH keys section of your settings tells you so: you’ll see an “SSH not permitted” state instead of the add-key form, because there’s nowhere a key could currently be used.
What to do:
- Use HTTPS instead. Clone and push over
https://frem.sh/<org>/<repo>.gitwith Git Credential Manager — this is the recommended path anyway, and it carries MFA on every token refresh. See Secure sign-in for setup. - For non-interactive clients, create a personal access token and use it as the HTTPS password.
- If you genuinely need SSH, ask an org owner to re-enable the SSH protocol for the org (Org admin → Authentication policy). Once any org you belong to allows SSH, the add-key form reappears here.
Cross-references
- Secure sign-in — HTTPS + GCM setup, the SSH opt-in path, and hardware-backed keys
- Keyless commit signing — identity-based signing with no key to manage
- API — using a PAT as a bearer token against the REST API