Autentiseringspolicy

Siden for autentiseringspolicy samler de organisasjonsomfattende innstillingene som avgjør hvordan medlemmene dine autentiserer seg mot Git og REST API-et. Hver bryter er uavhengig av de andre. Standardverdiene er de mest tillatende, slik at eksisterende medlemmer ikke plutselig blir låst ute første gang du åpner siden. Stram dem inn én om gangen etter hvert som sikkerhetsnivået ditt modnes.

Siden ligger under Sikkerhet › Tilgang › Autentiseringspolicy (<your-org>/_admin/security/access/authentication; den eldre adressen <your-org>/_admin/auth-policy videresender dit). Siden åpner også med informasjonen om tofaktorautentisering som tidligere lå på den avviklede siden Edge policies: tofaktorautentisering er alltid påkrevd, for alle medlemmer.

Samling 2026-05-26: den frittstående fanen Sertifikatutsteder (CA) for SSH ble flyttet inn på denne siden som en underseksjon under «Allow SSH protocol» (den gir bare mening når SSH er slått på, så den vises i takt med bryteren). Direkte lenker til /admin/ssh-ca/ videresender nå hit. De samme skrivemulighetene er bevart, lim inn CA-nøkler og slå krav om sertifikat av eller på, uten at du forlater visningen for autentiseringspolicy.

Policyer

Krav til SSH-nøkler

Når dette er slått på, avviser fremforge nye SSH-nøkler som ikke er maskinvarebaserte. Algoritmen til OpenSSH-nøkkelen forteller oss det: bare sk-ssh-ed25519@openssh.com og sk-ecdsa-sha2-nistp256@openssh.com godkjennes; vanlige ssh-ed25519 og ssh-rsa avvises i skjemaet Legg til nøkkel.

Maskinvarebasert betyr at den private nøkkelen ligger i en sikkerhetsbrikke (macOS Secure Enclave, TPM, YubiKey, FIDO-autentisering). Nøkkelen kan ikke hentes ut av den bærbare maskinen. Touch ID, PIN eller et trykk på maskinvaren kreves ved hver push. Dette er det nærmeste du praktisk kommer «MFA ved git push» uten et fullt oppsett med SSH-sertifikatutsteder.

Eksisterende nøkler avvises IKKE i ettertid: bare nye nøkler stoppes. Det er trygt å slå dette på i en organisasjon som fungerer: medlemmene kan fortsette å pushe med de nøklene de har, men en ny bærbar maskin krever maskinvarebasert oppsett. Kombiner med SSH-sertifikatutsteder nedenfor for den sterkeste sluttilstanden (ingen vanlige nøkler i det hele tatt).

Handlinger i revisjonsloggen: tenant.auth_policy.hardware_keys.enabled / tenant.auth_policy.hardware_keys.disabled.

SSH-sertifikatutsteder

(Vises bare når SSH-protokollen er slått på over; det er naturlig at en SSH-funksjon først dukker opp når SSH er på.)

Autentisering med SSH-sertifikater er den sterkeste praktiske måten å logge inn med SSH på. Et kortlivet sertifikat utstedt av din egen CA, knyttet til MFA-flyten i IdP-en din, erstatter den langlivede offentlige nøkkelen som ligger på hver utviklers bærbare maskin. fremforge har innebygd støtte for denne modellen, den samme mekanismen som GitHub Enterprise Cloud kaller «SSH certificate authority».

Forutsetning: siden 2026-05-22 får nye organisasjoner i fremforge SSH slått av som standard (bryteren over). Hvis organisasjonen din beholder standarden, trenger du ikke SSH CA i det hele tatt: veien med HTTPS + Git Credential Manager gir deg MFA ved hver push via IdP-en din uten noe CA-oppsett. Hvis organisasjonen din uttrykkelig har slått SSH på igjen (fordi du har en bestemt grunn, som eldre CI-verktøy eller sterke preferanser hos utviklerne), er denne seksjonen neste lag med herding for den valgte SSH-veien.

Når du bør bruke SSH CA

Bruk autentisering med SSH-sertifikater hvis organisasjonen din har slått SSH på igjen OG noe av følgende gjelder:

• Du vil at hver Git-push skal kreve en fersk MFA-utfordring fra IdP-en (ikke «bærbar maskin på avveie → angriperen pusher i 90 dager til noen oppdager SSH-nøkkelen»)
• Du migrerer fra GitHub Enterprise Cloud, og utviklerne dine forventer SSH CA-flyten fra GHEC
• Sikkerhetssjefen din har bedt spesifikt om «MFA ved Git-push» OG insisterer på SSH som transport; merk likevel at det ryddigere svaret er standardveien med HTTPS og GCM
• Du har allerede en CA som utsteder OpenSSH-sertifikater (Smallstep, HashiCorp Vault SSH secrets engine, en egen utsteder knyttet til OIDC) og vil at fremforge skal stole på sertifikatene den signerer

Hvis ingen av disse situasjonene gjelder deg, er maskinvarebaserte SSH-nøkler (Touch ID, Secure Enclave, YubiKey; bryteren over) en enklere vei med sammenlignbar sikkerhet. Se Sikker innlogging for valgmatrisen.

Oppsett

Steg 1: forbered CA-en din. Alternativene er ordnet etter hvor enkle de er:

1. Smallstep step ca: åpen kildekode, lett å hoste i EU, støtte for OIDC-provisjonering rett ut av boksen. Knytt den til IdP-en din, så blir step ssh login en MFA-flyt på én linje.
2. HashiCorp Vault SSH secrets engine: hvis du allerede kjører Vault for secrets, gir SSH secrets engine utstedelse av OpenSSH-sertifikater med policybasert tilgangskontroll.
3. Manuell ssh-keygen -s: bare til konseptbevis.

Generer nøkkelparet for CA-en hvis du ikke har et:

ssh-keygen -t ed25519 -f acme-ssh-ca -C "acme-ssh-ca@example.com"

Gir acme-ssh-ca (privat; hold den hemmelig og distribuer den til utstedelsesinfrastrukturen din) og acme-ssh-ca.pub (offentlig; limes inn i fremforge i neste steg).

Steg 2: registrer CA-en. Lim inn acme-ssh-ca.pub i tekstfeltet Trusted CA public keys på denne siden, én CA per linje. Opptil 8 CA-er godtas (nyttig ved rotasjon: legg til den nye, distribuer den nye private nøkkelen, avvikle den gamle). Klikk Save CA keys. En automatisk plattformjobb sprer endringen til SSH-laget i Forgejo. Oppføring i revisjonsloggen: tenant.ssh_ca.keys.updated.

Steg 3: la medlemmene registrere sine principals. Hvert SSH-sertifikat har én eller flere principals, korte strenger som angir hvem sertifikatet er for. Et sertifikat signert av en klarert CA logger inn et medlem når en av principalene i sertifikatet matcher en principal som medlemmet har registrert på sin egen side for SSH-nøkler (seksjonen Administrer principaler for SSH-sertifikater). fremforge godtar hvilken som helst principal-streng der, så utsted sertifikater der principalen entydig identifiserer brukeren, for eksempel brukernavnet i fremforge.

Fjernet 2026-10-14: innstillingen «Principal policy» (Username / Email / Anything). Den ble lagret, men aldri håndhevet: Forgejo kontrollerer formen på en principal mot én innstilling for hele plattformen, ikke én per organisasjon, og et medlem kan høre til flere organisasjoner. API-ets PUT /orgs/{org}/ssh-ca godtar fortsatt principal_policy, slik at eksisterende skript og Terraform fortsetter å virke, men ignorerer den, og GET returnerer den ikke lenger.

Steg 4: krev eventuelt sertifikatautentisering. Når minst én CA er konfigurert, slår du på Require CA-signed certificate for å avvise vanlig autentisering med offentlig SSH-nøkkel. Dette er den ryddigste sluttilstanden: langlivede ~/.ssh/id_*-nøkler slutter helt å virke, og hver Git-push må gå via CA-en din (og dermed MFA-flyten i IdP-en din). Å slå dette på uten en fungerende CA ville låst alle ute; skjemaet avviser endringen når ingen CA er konfigurert. Oppføringer i revisjonsloggen: tenant.ssh_ca.require_cert.enabled / tenant.ssh_ca.require_cert.disabled.

Steg 5: utsted brukernes første sertifikat. Med Smallstep:

step ssh login user@example.com --provisioner=your-oidc-provisioner
# Browser opens → IdP login + MFA → cert issued + cached ~1 hour.

git clone git@frem.sh:<org>/<repo>.git
# OpenSSH presents the cert; fremforge checks the trusted CA and the user's registered principals.

For Vault, se dokumentasjonen for HashiCorp Vault SSH secrets engine. For manuell ssh-keygen -s (bare konseptbevis): ssh-keygen -s acme-ssh-ca -I "alice-cert-2026-05-22" -n alice -V +1h alice-id_ed25519.pub → distribuer alice-id_ed25519-cert.pub til brukeren sammen med den private nøkkelen; OpenSSH plukker det opp automatisk.

Rotere CA-en

Slik bytter du ut en eksisterende CA uten avbrudd: generer et nytt nøkkelpar for CA-en → legg den nye offentlige nøkkelen inn i tekstfeltet ved siden av den eksisterende (opptil 8 godtas) → oppdater CA-infrastrukturen til å utstede med den nye nøkkelen → vent til sertifikatene fra den gamle CA-en har utløpt (typisk 1 time) → fjern den gamle CA-en fra tekstfeltet.

Slå av CA-autentisering

Fjern alle CA-nøkler fra tekstfeltet og lagre. Oppføringen tenant.ssh_ca.keys.updated i revisjonsloggen registrerer next_key_count: 0. Hvis Require CA-signed certificate var på, slås den av automatisk (bryteren krever minst én CA). Medlemmene går tilbake til vanlig autentisering med offentlig SSH-nøkkel.

Levetid for PAT-er

Høyeste tillatte levetid for nyopprettede personlige tilgangstokener. Eksisterende tokener blir IKKE forkortet i ettertid; taket gjelder bare ved utstedelse.

Anbefalt: 90 dager som utgangspunkt. Stram inn til 30 hvis du har et aktivt program for skanning etter legitimasjon som fanger lekkede tokener innenfor rotasjonsperiodene.

Handling i revisjonsloggen: tenant.auth_policy.max_pat_lifetime.updated.

Tillat deploy-nøkler i repositoryer

Deploy-nøkler i repositoryer er langlivet SSH-legitimasjon avgrenset til ett enkelt repository, en parallell vei for langlivet maskinlegitimasjon ved siden av brukernes PAT-er. Nyttig for ekstern CI eller speilklienter som ikke kan føderere via OIDC. Standard: av, i tråd med den sikre standarden ssh_disabled=true og allow_user_pats=false. Langlivet maskinlegitimasjon er av til du velger den.

Når policyen er av (standard), slår tre lag inn:

1. Banner i Forgejos grensesnitt: når en repository-administrator åpner Repo-innstillinger → Deploy-nøkler, sendes siden gjennom api-intercept, som legger inn et banner i Fomantic-stil over den vanlige Forgejo-toppteksten og forklarer at deploy-nøkler er slått av av organisasjonens policy. Forgejos navigasjon og sidemeny er bevart (brukeren blir aldri kastet ut av repositoryet). Innsending av skjemaet Legg til deploy-nøkkel blokkeres i API-et (POST omdirigeres med 303 tilbake til GET, så brukeren ser forklaringen i banneret).
2. Blokkering i REST API-et: POST /api/v1/repos/<owner>/<repo>/keys svarer med 403 med error: use_fremforge_admin og redirect_to som peker hit. DELETE og GET sendes alltid videre (administratorer kan rydde opp i og revidere eksisterende nøkler uansett policy).
3. Myk advarsel i revisjonsloggen: hver eksisterende aktiv deploy-nøkkel sender en revisjonshendelse tenant.auth_policy.deploy_key_violation ved neste gjennomgang. Eksisterende nøkler tilbakekalles IKKE automatisk; administratoren bestemmer hvilke som skal bort via innstillingene for repositoryet i Forgejo (slettingen er fortsatt åpen).

Når du bør slå det på: bare i nisjetilfellet med ekstern CI eller speilklienter som virkelig ikke kan føderere med OIDC. Det tiltenkte alternativet for maskinidentitet i CI er OIDC-føderasjon for runnere: kortlivede tokener utstedt av fremforges OIDC-utsteder og føderert til tillitspolicyen i skyen din, uten langlivede secrets per repository. De fleste CI-integrasjoner trenger ikke deploy-nøkler.

Handlinger i revisjonsloggen: tenant.auth_policy.allow_repo_deploy_keys.enabled / .disabled (bryteren); tenant.auth_policy.deploy_key_violation (per aktiv nøkkel mens policyen er av).

Krev signerte commits

Når dette er slått på, har standardbranchen i hvert repository i organisasjonen en regel for branchbeskyttelse som krever signerte commits. Medlemmene må sette opp GPG- eller SSH-signering av commits på maskinene sine; usignerte commits til standardbranchen avvises av Forgejo ved push.

Innstillingen trer i kraft så snart du lagrer den. fremforge begynner med en gang å bruke den på organisasjonens eksisterende repositoryer, i bakgrunnen, og linjen under bryteren i Sikkerhet › Policyer › Regler for repositoryer viser framdriften og når den ble ferdig. En kontroll hver time holder deretter hver standardbranch i tråd med innstillingen, også for repositoryer som opprettes senere. Lagrer du samme verdi på nytt, starter en ny kontroll.

Slår du den av, slås kravet av igjen, også med en gang, i reglene fremforge slo på for denne innstillingen. En regel der en repository-administrator selv krevde signerte commits, blir stående som den er, og det samme gjelder resten av hver regel: godkjenninger og statussjekker røres ikke, og ingen regel slettes. Hvis en administrator har krysset av for «require signed commits» for hånd på en regel fremforge allerede hadde satt, kan fremforge ikke skille de to; den regelen slås av sammen med de andre, og administratoren kan sette den på nytt.

Det er én innstilling sammen med standarden for signerte commits i nye repositoryer: når du lagrer, settes begge, så et nytt repository starter med samme krav (se Repository rules).

Bryteren er organisasjonens minimum; overstyringer av branchbeskyttelse per repository gjelder hvis de er satt.

Gjennom API-et gjør PATCH /orgs/{org}/auth-policy med require_signed_commits det samme og svarer signed_commits_applying: true.

Oppsett av signering for medlemmer:

# Generate a signing key (or use the existing SSH key)
ssh-keygen -t ed25519 -f ~/.ssh/git-signing-key -C "alice signing key"

# Configure git to sign with it
git config --global user.signingkey ~/.ssh/git-signing-key.pub
git config --global gpg.format ssh
git config --global commit.gpgsign true

# Upload the public key to frem.sh/user/settings/keys with usage:
# "Signing key" alongside the same key as an "Authentication key".

Handlinger i revisjonsloggen: tenant.auth_policy.signed_commits.enabled / tenant.auth_policy.signed_commits.disabled (innstillingen); tenant.auth_policy.signed_commits.applied / tenant.auth_policy.signed_commits.reverted (per regel i et repository som fremforge endret).

Tillat SSH-protokollen

Denne bryteren styrer om Git over SSH i det hele tatt er tillatt. Av (standard for organisasjoner opprettet etter 2026-05-22) betyr at hver Git-operasjon over SSH mot organisasjonens repositoryer avvises: push, clone og fetch, og Git LFS over SSH. Clone og fetch avvises før Git starter; en push avvises i pre-receive-hooken. En avvist clone eller fetch viser en melding som nevner denne innstillingen og oppgir HTTPS-klone-URL-en som skal brukes i stedet (se Hva en avvist utvikler ser). Medlemmene bruker HTTPS og Git Credential Manager, som bærer MFA gjennom organisasjonens IdP ved hver fornyelse av tokenet. Slå bryteren på for å tillate SSH (den gamle standarden fra før 2026-05-22).

Hvorfor dette finnes: IP-tillatelseslisten dekker ikke Git over SSH. SSH når fremforge gjennom en lastbalanserer som erstatter kildeadressen med adressen til en av våre egne klyngenoder, så adressen utvikleren kobler til fra, er ikke synlig for oss, og fremforge nekter å vurdere en forbindelse ut fra en adresse den vet er feil. Organisasjoner som vil at hver Git-operasjon skal filtreres på IP, slår av SSH her og bruker HTTPS, som tillatelseslisten dekker.

Hva en avvist utvikler ser

En git clone eller git fetch over SSH mot et repository i en organisasjon med SSH slått av, feiler med:

$ git clone git@frem.sh:acme/web.git
Cloning into 'web'...
Forgejo: SSH is turned off for the organisation acme (Authentication policy: "Allow SSH protocol" is off), so SSH push, clone and fetch are refused. Use HTTPS instead: git clone https://frem.sh/acme/web.git

fatal: Could not read from remote repository.

Utviklerens SSH-nøkler og medlemskap i organisasjonen røres ikke: slår du bryteren på igjen, er SSH-tilgangen tilbake med en gang.

Hver avvisning registreres i revisjonsloggen som git.ssh.tenant_disabled_blocked, både for push og for clone og fetch.

Handlinger i revisjonsloggen: tenant.auth_policy.ssh_disabled.enabled / tenant.auth_policy.ssh_disabled.disabled.

IP-tillatelsesliste

IP-tillatelseslisten har flyttet til en egen side: IP-tillatelsesliste. Én liste dekker nå hver HTTPS-flate, så den har ikke lenger et omfang å velge. Forhåndsvisningen som bare logger, bryteren for runnere og break-glass er beskrevet der.

Oppbevaring av revisjonsloggen

Styrer perioden der innholdet i revisjonsloggen er søkbart. Det kryptografiske kjedelaget (3 år WORM) påvirkes ikke av denne innstillingen; bare de lesbare kolonnene actor og fields_json endres.

Innstillingen brukes ved den daglige sladdingen (~02:30 UTC). Forlenger du perioden, forblir nye rader søkbare lenger; forkorter du den, sladdes rader som er eldre enn den nye perioden, ugjenkallelig ved neste gjennomgang. Se Revisjonslogg → Oppbevaring for hele mekanismen.

Handling i revisjonsloggen: tenant.auth_policy.audit_retention.updated.

Hvordan de virker sammen

Hva som håndhever hva

Disse policyene håndheves i plattformlaget ved hver forespørsel. Admingrensesnittet er fasiten for hva organisasjonen har valgt.

Begrensninger

• Taket for levetiden til PAT-er gjelder ved utstedelse. Eksisterende tokener blir IKKE forkortet i ettertid. Hvis du strammer inn taket, må du regne med at noen bot- og CI-tokener lever lenger enn den nye policyen; de virker fortsatt til sin opprinnelige utløpstid.
• Håndheving av maskinvarenøkler gjelder bare NYE nøkler. Medlemmene beholder eksisterende nøkler.
• Signerte commits brukes på eksisterende repositoryer når innstillingen lagres, i bakgrunnen; i en stor organisasjon tar det et minutt eller to, og framdriften vises under bryteren. Nye repositoryer som opprettes etter at bryteren er slått på, får regelen når de opprettes.