Gå til hovedindhold

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

EgenskabHTTPS + GCMSSHPAT
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 legitimationsoplysningerKortlivede OAuth-tokens, fornyes automatiskLanglivet nøgle (indtil den roteres)Kan konfigureres, ofte måneder
Opsætning for udviklerenInstallér GCM én gang + to git config-linjerGenerér nøgle + upload til fremforge + konfigurér agentOpret token i brugerfladen + indsæt i gits credential store
Skadens omfang ved en bortkommet bærbarAngriberen skal bruge din IdP-adgangskode + MFA – lille vindueNøglefilen alene er nok – stort vindueTokenet 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-a874fb9e0662

OAuth-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>.git

GCM å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 / Linux

Reservelø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):

  1. Organisationsadministratoren går til <your-org>/_admin/auth-policy og sætter flueben ved “Tillad SSH-protokol” – og accepterer dermed den dokumenterede begrænsning, at IP-tilladelseslisten ikke gælder for SSH.
  2. Medlemmerne tilføjer SSH-nøgler på frem.sh/user/settings/keys og konfigurerer deres ~/.ssh/config:
Host frem.sh
    Hostname ssh.frem.sh
    Port 443
    IdentityFile ~/.ssh/id_ed25519
  1. Brug hardwarebaserede nøgler, hvor det er muligt (ssh-add --apple-use-keychain på macOS til Touch ID; ssh-keygen -t ed25519-sk til 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:user og 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/userinfo og /login/oauth/introspect og får 401 på 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_ed25519

Touch 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_sk

Kræ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:

  1. WSL2 – følg Linux-flowet inde i WSL2.
  2. 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 expiry

Hvad 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 ed25519 uden 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