Sikkert login
Den anbefalede vej til Git-login for menneskelige udviklere er HTTPS + Git Credential Manager (GCM) – interaktivt login gennem din organisations IdP med MFA ved hver fornyelse af tokenet. SSH er slået fra som standard i nye fremforge-organisationer; erfarne udviklere, der har et konkret behov for SSH, kan bede deres organisationsadministrator om at slå det til igen. Denne side beskriver opsætningen af GCM på macOS, Linux og Windows plus et afsnit om reserveløsningerne SSH og PAT’er.
Hvorfor HTTPS + GCM er standard
| Egenskab | HTTPS + GCM | SSH | PAT |
|---|---|---|---|
| MFA ved push | ✅ via din organisations IdP, ved hver fornyelse af tokenet | ❌ nøglen går uden om MFA | ❌ statisk bearer-token |
| Kilde-IP kan håndhæves af organisationsadministratoren | ✅ Fuldt ud | ⚠️ Ikke muligt arkitektonisk (Forgejos indbyggede SSH + load balancerens SNAT) | ✅ Fuldt ud |
| Levetid for legitimationsoplysninger | Kortlivede OAuth-tokens, fornyes automatisk | Langlivet nøgle (indtil den roteres) | Kan konfigureres, ofte måneder |
| Opsætning for udvikleren | Installér GCM én gang + to git config-linjer | Generér nøgle + upload til fremforge + konfigurér agent | Opret token i brugerfladen + indsæt i gits credential store |
| Skadens omfang ved en bortkommet bærbar | Angriberen skal bruge din IdP-adgangskode + MFA – lille vindue | Nøglefilen alene er nok – stort vindue | Tokenet alene er nok – indtil det roteres |
GCM er Microsofts open source-credential helper; fremforge integrerer med den via Forgejos indbyggede OAuth2-udbyder. Virker på udviklerarbejdsstationer med Windows, macOS og Linux.
HTTPS + Git Credential Manager (anbefalet)
Trin 1: installér GCM
# macOS via Homebrew
brew install --cask git-credential-manager
# Linux (Debian/Ubuntu, Fedora, etc. — see GCM repo for distro-specific paths)
curl -sL https://aka.ms/gcm/linux-install-source.sh | sh
git-credential-manager configure
# Windows — bundled with Git for Windows 2.28+ (re-installer prompt offers GCM)Trin 2: konfigurér GCM til fremforge
Kør dette én gang pr. arbejdsstation:
# Tell GCM to use the Forgejo/Gitea OAuth provider for frem.sh URLs.
git config --global credential.https://frem.sh.gitProvider gitea
# Use fremforge's pre-registered Git Credential Manager OAuth application.
# Same client_id across every fremforge org — your sign-in still goes
# through your org's own IdP (the per-tenant OIDC source registered at
# /<your-org>/_admin/sso).
git config --global credential.https://frem.sh.oauthClientId e90ee53c-94e2-48ac-9358-a874fb9e0662OAuth-applikationen er den indbyggede git-credential-manager-klient, der følger med Forgejo – der kræves ingen registrering pr. instans; det samme klient-id virker mod alle fremforge-instanser og alle Forgejo-baserede Git-værter. Klienten bruger PKCE (Proof Key for Code Exchange), så der skal ikke ligge noget client_secret på udviklerens maskine. Loopback-callbacks (http://127.0.0.1, http://localhost) accepteres på en hvilken som helst port i henhold til RFC 8252 §7.3.
Trin 3: clone over HTTPS
git clone https://frem.sh/<your-org>/<your-repo>.gitGCM åbner en fane i browseren → frem.sh beder om din e-mailadresse (så vi ved, hvilken organisation du hører til) → du sendes videre til din organisations egen login-side → kun din organisations IdP-knap(per) vises → indtast adgangskode + MFA hos din IdP → browseren vender tilbage til GCM → tokenet gemmes. Andre organisationers IdP’er er aldrig synlige. Efterfølgende clone, fetch og push inden for tokenets levetid sker i stilhed.
Adgangstokens gælder i 24 timer – inden for det vindue sker hvert git push i stilhed. Fornyelsestokens gælder i 30 dage, så det næste push efter adgangstokenets udløb fornyer det uden at åbne browseren. Hver maskine, du logger ind fra, beholder sit eget gyldige login, så når du bruger git på både en bærbar og en stationær computer (eller i WSL), skal ingen af dem logge ind igen. Efter 30 dage uden push eller fetch åbner det næste igen browseren, og din MFA udløses via din IdP.
Når GCM åbner browseren for at logge ind på ny (en ny enhed, efter du har logget ud, eller efter 30 dage uden brug), beder frem.sh dig først bekræfte, at det er dig, med din godkendelsesapp eller sikkerhedsnøgle. Det sker cirka én gang om måneden på hver enhed; når login fornyes i baggrunden, bliver du aldrig spurgt. Se Hvorfor bliver jeg bedt om at bekræfte, at det er mig?
Trin 4: valgfrit – fornuftige standardindstillinger
# Cache the OAuth token between sessions instead of re-running the
# browser flow every laptop reboot. GCM stores it in the OS keychain
# (macOS Keychain / Windows Credential Manager / Linux libsecret).
git config --global credential.credentialStore gpg # Linux only
git config --global credential.guiPrompt true # macOS / LinuxReserveløsninger
Personligt adgangstoken (kun til CI-bots og scripts)
PAT’er er statiske bearer-legitimationsoplysninger uden MFA. De er fine til automatisering uden opsyn, men aldrig til push fra mennesker.
# 1. Mint at frem.sh/user/settings/applications
# 2. Set expiry to the shortest practical value (30 days for routine,
# 90 days for stable CI). If your org admin has set a max lifetime
# policy, the mint page caps the dropdown automatically.
# 3. Use as the password for HTTPS clone:
git clone https://<your-username>:<pat>@frem.sh/<org>/<repo>.git
# Or via GCM's "store in keychain" path so you don't bake it into URLs:
git -c credential.helper=store clone https://frem.sh/<org>/<repo>.git
# Enter username + paste PAT when prompted; cached in ~/.git-credentials.OIDC-tokens fra Forgejo Actions (CI-workloadidentitet, ingen statiske legitimationsoplysninger)
Til CI/CD, der udruller til AWS / Azure / GCP / T Cloud Public, bør du foretrække fødereret identitet frem for PAT’er. fremforge giver CI-jobs kortlivede OIDC-tokens fra sin runner-OIDC-udsteder, https://frem.sh/_app/runner/oidc (discovery på https://frem.sh/_app/runner/oidc/.well-known/openid-configuration); konfigurér din cloududbyders IAM til at stole på den udsteder. Claims (sub, aud, repository_owner) står også på siden nedenfor. Se Runner OIDC for skabeloner til trust-politikker for hver cloud.
SSH (kun når din organisationsadministrator udtrykkeligt har slået det til)
Nye fremforge-organisationer har SSH slået fra som standard. Har din organisation brug for SSH (ældre CI, stærk præference blandt udviklerne for flowet med SSH-nøgler):
- Organisationsadministratoren går til
<your-org>/_admin/auth-policyog sætter flueben ved “Tillad SSH-protokol” – og accepterer dermed den dokumenterede begrænsning, at IP-tilladelseslisten ikke gælder for SSH. - Medlemmerne tilføjer SSH-nøgler på
frem.sh/user/settings/keysog konfigurerer deres~/.ssh/config:
Host frem.sh
Hostname ssh.frem.sh
Port 443
IdentityFile ~/.ssh/id_ed25519- Brug hardwarebaserede nøgler, hvor det er muligt (
ssh-add --apple-use-keychainpå macOS til Touch ID;ssh-keygen -t ed25519-sktil FIDO/YubiKey på Linux). Se afsnittet om hardwarebaserede SSH-nøgler nedenfor.
Dine egne OAuth-applikationer: bed om eksplicitte scopes
Registrerer du en OAuth2-applikation på frem.sh (Indstillinger › Applikationer for brugeren eller organisationen) for at logge folk ind eller kalde API’et på deres vegne, kan dens token kun det, de scopes, den har bedt om, tillader:
- API-scopes (
read:repository,write:issue,read:userog resten): tokenet virker på API’et og på Git over HTTPS inden for de scopes, som hidtil. - Kun
openid,profile,email,groups: tokenet logger personen ind og intet andet. Det virker på/login/oauth/userinfoog/login/oauth/introspectog får401på API’et, pakke-registries og Git. - Intet scope overhovedet: det samme, kun login. Kun fremforges egne klienter (Git Credential Manager konfigureret som ovenfor og
fremforge-CLI’en) beholder fuld adgang uden scope.
En applikation, der skal bruge API’et, skal derfor bede om de API-scopes, den har brug for, i parameteren scope til /login/oauth/authorize. Har den allerede en tilladelse med et andet scope, tilbagekalder personen den tilladelse under Autoriserede OAuth2-applikationer på frem.sh/user/settings/applications og logger ind igen.
Hardwarebaserede SSH-nøgler (for organisationer, der har slået SSH til igen)
Har din organisationsadministrator slået SSH til igen, og har du reelt brug for det, er hardwarebaserede nøgler obligatorisk god praksis. Organisationspolitikken “Kræv hardwarebaserede SSH-nøgler” afviser allerede ved registreringen enhver nøgle, der ikke hører til sk-*-familien af algoritmer.
macOS – Secure Enclave
ssh-keygen -t ed25519 -C "your-name@your-org" -f ~/.ssh/id_ed25519
ssh-add --apple-use-keychain ~/.ssh/id_ed25519Touch ID spørger ved hvert push, hvis macOS-nøgleringen ikke for nylig har låst nøglen op. Vil du have, at nøglen udelukkende ligger i Secure Enclave (genereret og opbevaret helt inde i chippen), så brug Secretive.
Linux – YubiKey / FIDO-autentifikator
ssh-keygen -t ed25519-sk -C "your-name@your-org" -f ~/.ssh/id_ed25519_sk
ssh-add ~/.ssh/id_ed25519_skKræver OpenSSH 8.2+ (februar 2020) for ed25519-sk; ecdsa-sk er reserveløsningen på ældre distributioner.
Windows – TPM-baseret via WSL2 / KeePassXC
Windows’ indbyggede OpenSSH giver ikke direkte adgang til TPM’en. To muligheder:
- WSL2 – følg Linux-flowet inde i WSL2.
- SSH-agenten i KeePassXC / 1Password – begge opbevarer nøgler beskyttet af Windows Hello-biometri.
Beslutningstræ
Are you a human developer pushing code daily?
├── Yes → HTTPS + GCM (the recommended default; no SSH key needed)
│ ├── If your org has re-enabled SSH and you prefer it → hardware-backed SSH key
│ └── If you specifically need a static credential → PAT with 30-day expiry
└── No, I'm a CI bot or script
├── Cloud-deploying → Forgejo Actions OIDC token (no static cred)
└── Other → PAT with tight scope + short expiryHvad du IKKE skal gøre
- Langlivede PAT’er i git-konfigurationsfiler /
.netrc. Statiske bearer-legitimationsoplysninger uden udløb er det værste godkendelsesmønster. Brug GCM til mennesker, OIDC-tokens til CI og PAT’er med kort udløb til ældre bots. - Almindelig
ssh-keygen -t ed25519uden hardware bag eller krav fra organisationen. Nøglen ligger i~/.ssh/; en bortkommet bærbar = en kompromitteret nøgle i hele nøglens levetid. - At springe MFA over med mønstre, hvor man “altid stoler på SSH-nøglen”. Har din organisation brug for håndhævelse på niveau med en IP-tilladelsesliste, betyder det HTTPS – fremforges IP-tilladelsesliste håndhæves i realtid på HTTPS og er ikke mulig arkitektonisk på SSH.
- At slå SSH til igen, fordi “det er hurtigere”. Forskellen i besvær ved opsætningen er ubetydelig efter den første dag; forskellen i sikkerhedsniveau er reel.
Reference for organisationsadministratorer
Er du ejer af en organisation og fastsætter politikker:
- Vejledning til godkendelsespolitikken – kontakten til at slå SSH fra, krav om hardwarebaserede SSH-nøgler, SSH-certifikatmyndighed (lagt ind her 2026-05-26), maksimal levetid for PAT’er, kontakten Tillad deploy-nøgler på repoer, signerede commits, IP-tilladelseslistens omfang + forhåndsvisning med kun revision