Autentiseringspolicy

Sidan för autentiseringspolicy samlar de organisationsövergripande inställningar som avgör hur dina medlemmar autentiserar sig mot Git och REST-API:et. Varje reglage är fristående. Standardvärdena är de mest tillåtande, så att befintliga medlemmar inte oväntat stängs ute första gången du öppnar sidan. Skärp dem ett i taget i takt med att din säkerhetsnivå mognar.

Sidan finns under Säkerhet › Åtkomst › Autentiseringspolicy (<your-org>/_admin/security/access/authentication; den äldre adressen <your-org>/_admin/auth-policy omdirigeras dit). Sidan inleds också med den information om tvåfaktorsautentisering som tidigare fanns på den borttagna sidan Edge-policyer: tvåfaktorsautentisering krävs alltid, för varje medlem.

Sammanslagning 2026-05-26: den fristående fliken SSH-certifikatutfärdare har flyttats in på den här sidan som ett underavsnitt under “Tillåt SSH-protokollet” (den är bara meningsfull när SSH är påslaget, så den visas i takt med reglaget). Direktlänkar till /admin/ssh-ca/ omdirigeras nu hit. Samma möjligheter finns kvar (klistra in CA-nycklar, slå på krav på certifikat) utan att du lämnar sidan för autentiseringspolicy.

Policyer

Krav på SSH-nycklar

När detta är påslaget avvisar fremforge nya SSH-nycklar som inte är hårdvarubaserade. Det är OpenSSH-nyckelns algoritm som avgör: bara sk-ssh-ed25519@openssh.com och sk-ecdsa-sha2-nistp256@openssh.com godtas, medan vanliga ssh-ed25519 och ssh-rsa avvisas i formuläret Lägg till nyckel.

Hårdvarubaserad betyder att den privata nyckeln ligger i ett säkerhetschip (macOS Secure Enclave, TPM, YubiKey, FIDO-autentiserare). Nyckeln kan inte föras ut från datorn. Touch ID, PIN eller en tryckning på hårdvaran krävs vid varje push. Det är det som i praktiken ligger närmast “MFA vid git push” utan en fullständig SSH-certifikatutfärdare.

Befintliga nycklar avvisas INTE retroaktivt, det är bara nya nycklar som kontrolleras. Det är säkert att slå på detta i en fungerande organisation: medlemmarna kan fortsätta pusha med sina befintliga nycklar, men en ny dator kräver en hårdvarubaserad nyckel. Kombinera med SSH-certifikatutfärdare nedan för det starkaste slutläget (inga vanliga nycklar alls).

Åtgärder i granskningsloggen: tenant.auth_policy.hardware_keys.enabled / tenant.auth_policy.hardware_keys.disabled.

SSH-certifikatutfärdare

(Syns bara när SSH-protokollet är påslaget ovan. En SSH-funktion visas naturligt bara när SSH är på.)

Autentisering med SSH-certifikat är det starkaste praktiska sättet att logga in över SSH. Ett kortlivat certifikat som utfärdas av din egen CA och är knutet till din IdP:s MFA-flöde ersätter den långlivade publika nyckel som annars ligger på varje utvecklares dator. fremforge har inbyggt stöd för den här modellen, samma funktion som GitHub Enterprise Cloud kallar “SSH certificate authority”.

Förutsättning: sedan 2026-05-22 har nya organisationer i fremforge SSH avslaget som standard (reglaget ovan). Behåller din organisation standardvärdet behöver du ingen SSH-CA alls: vägen med HTTPS + Git Credential Manager ger dig MFA vid varje push via din IdP utan någon CA. Har din organisation uttryckligen slagit på SSH igen (av ett särskilt skäl, till exempel äldre CI-verktyg eller att utvecklarna föredrar det) är det här avsnittet nästa nivå av härdning för den SSH-vägen.

När du ska använda SSH-CA

Använd autentisering med SSH-certifikat om din organisation har slagit på SSH igen OCH något av följande gäller:

• Du vill att varje Git-push ska kräva en ny MFA-kontroll i IdP:n (ingen “förlorad dator → angriparen pushar i 90 dagar tills någon märker SSH-nyckeln”)
• Du migrerar från GitHub Enterprise Cloud och utvecklarna förväntar sig GHEC:s SSH-CA-flöde
• Din CISO har bett specifikt om “MFA vid Git-push” OCH insisterar på SSH som transport, men notera att det renare svaret är standardvägen med HTTPS+GCM
• Du har redan en CA som utfärdar OpenSSH-certifikat (Smallstep, HashiCorp Vaults SSH secrets engine, en egen OIDC-bunden utfärdare) och vill att fremforge ska lita på certifikat som den signerar

Gäller inget av detta är hårdvarubaserade SSH-nycklar (Touch ID, Secure Enclave, YubiKey, reglaget ovan) en enklare väg med jämförbar säkerhet. Se Säker inloggning för en jämförelse av alternativen.

Konfiguration

Steg 1: förbered din CA. Alternativen i ordning efter hur enkla de är:

1. Smallstep step ca: öppen källkod, lätt att drifta inom EU, stöd för OIDC-provisioner direkt. Koppla den till din IdP så blir step ssh login ett MFA-flöde på en rad.
2. HashiCorp Vaults SSH secrets engine: kör du redan Vault för hemligheter lägger SSH secrets engine till utfärdande av OpenSSH-certifikat med policybaserad åtkomstkontroll.
3. Manuellt med ssh-keygen -s: bara för konceptbevis.

Skapa CA-nyckelparet om du inte redan har ett:

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

Det ger acme-ssh-ca (privat: håll den hemlig och distribuera den till din utfärdande infrastruktur) och acme-ssh-ca.pub (publik: klistras in i fremforge i nästa steg).

Steg 2: registrera CA:n. Klistra in acme-ssh-ca.pub i textfältet Publika CA-nycklar (en per rad) på den här sidan, en CA per rad. Upp till 8 CA:er godtas (användbart vid rotation: lägg till den nya, distribuera den nya privata nyckeln, ta bort den gamla). Klicka på Save CA keys. Ett automatiskt plattformsjobb för in ändringen i Forgejos SSH-lager. Post i granskningsloggen: tenant.ssh_ca.keys.updated.

Steg 3: låt medlemmarna registrera sina principals. Varje SSH-certifikat bär en eller flera principals, korta strängar som anger vem certifikatet gäller. Ett certifikat som signerats av en betrodd CA loggar in en medlem när en av dess principals matchar en principal som medlemmen har registrerat på sin egen sida för SSH-nycklar (avsnittet Manage SSH certificate principals). fremforge godtar vilken principal-sträng som helst där, så utfärda certifikat vars principal entydigt pekar ut användaren, till exempel hens användarnamn i fremforge.

Borttagen 2026-10-14: inställningen “Principal policy” (Username / Email / Anything). Den sparades men tillämpades aldrig: Forgejo kontrollerar en principals form mot en enda plattformsgemensam inställning, inte en per organisation, och en medlem kan tillhöra flera organisationer. API:ets PUT /orgs/{org}/ssh-ca godtar fortfarande principal_policy så att befintliga skript och Terraform fortsätter fungera, men ignorerar det, och GET returnerar det inte längre.

Steg 4: kräv eventuellt certifikatautentisering. När minst en CA är konfigurerad kan du slå på Kräv CA-signerat certifikat (ingen vanlig autentisering med publik nyckel) för att avvisa vanlig SSH-autentisering med publik nyckel. Det är det renaste slutläget: långlivade ~/.ssh/id_*-nycklar slutar fungera helt, och varje Git-push måste gå via din CA (och därmed din IdP:s MFA-flöde). Att slå på detta utan en fungerande CA skulle stänga ute alla, så formuläret avvisar ändringen när ingen CA är konfigurerad. Poster i granskningsloggen: tenant.ssh_ca.require_cert.enabled / tenant.ssh_ca.require_cert.disabled.

Steg 5: utfärda användarnas första certifikat. 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.

För Vault, se dokumentationen för HashiCorp Vaults SSH secrets engine. Manuellt med ssh-keygen -s (bara konceptbevis): ssh-keygen -s acme-ssh-ca -I "alice-cert-2026-05-22" -n alice -V +1h alice-id_ed25519.pub → ge alice-id_ed25519-cert.pub till användaren tillsammans med hens privata nyckel; OpenSSH hittar den automatiskt.

Rotera CA:n

Så byter du ut en befintlig CA utan avbrott: skapa ett nytt CA-nyckelpar → lägg till den nya publika nyckeln i textfältet bredvid den befintliga (upp till 8 godtas) → låt din CA-infrastruktur utfärda med den nya nyckeln → vänta tills certifikat från den gamla CA:n har gått ut (vanligtvis 1 timme) → ta bort den gamla CA:n ur textfältet.

Stänga av CA-autentisering

Ta bort alla CA-nycklar ur textfältet och spara. Posten tenant.ssh_ca.keys.updated i granskningsloggen registrerar next_key_count: 0. Var Kräv CA-signerat certifikat påslaget stängs det av automatiskt (reglaget kräver minst en CA). Medlemmarna går tillbaka till vanlig SSH-autentisering med publik nyckel.

PAT-livslängd

Den längsta tillåtna livslängden för nyskapade personliga åtkomsttokens. Befintliga tokens förkortas INTE retroaktivt; gränsen gäller bara när en token utfärdas.

Rekommendation: börja med 90 dagar. Skärp till 30 om du har ett aktivt program för hemlighetsskanning som fångar läckta tokens inom rotationsfönstret.

Åtgärd i granskningsloggen: tenant.auth_policy.max_pat_lifetime.updated.

Tillåt deploy keys på repon

Deploy keys på repon är långlivade SSH-uppgifter avgränsade till ett enda repo, en parallell väg för långlivade maskinuppgifter vid sidan av användarnas PAT:ar. De är användbara för externa CI- eller spegelklienter som inte kan federera via OIDC. Standard: av, i linje med den säkra standardhållningen ssh_disabled=true och allow_user_pats=false. Långlivade maskinuppgifter är avstängda tills du aktivt slår på dem.

När policyn är av (standard) gäller tre lager:

1. Banner i Forgejo: när en repoadministratör öppnar Repoinställningar → Distributionsnycklar skickas sidan via api-intercept, som lägger in en banner i Fomantic-stil ovanför Forgejos vanliga sidhuvud och förklarar att deploy keys är avstängda av organisationens policy. Forgejos navigering och sidofält finns kvar (användaren skickas aldrig ut ur repot). Formuläret Lägg till distributionsnyckel blockeras i api (POST omdirigeras med 303 tillbaka till GET, så att användaren ser bannerns förklaring).
2. Blockering i REST-API:et: POST /api/v1/repos/<owner>/<repo>/keys returnerar 403 med error: use_fremforge_admin och redirect_to som pekar hit. DELETE och GET skickas alltid vidare (operatörer kan städa bort och granska befintliga nycklar oavsett policy).
3. Mjuk varning i granskningsloggen: varje befintlig aktiv deploy key ger en händelse tenant.auth_policy.deploy_key_violation vid nästa kontrollkörning. Befintliga nycklar återkallas INTE automatiskt; operatören avgör vilka som ska bort via Forgejos repoinställningar (borttagningsvägen förblir öppen).

När du bör slå på den: bara i specialfallet med externa CI- eller spegelklienter som verkligen inte kan federera via OIDC. Det tänkta alternativet för CI:s maskinidentitet är runner-OIDC-federering: kortlivade tokens från fremforges OIDC-utfärdare, federerade mot molnleverantörens förtroendepolicy, utan någon långlivad hemlighet per repo. De flesta CI-integrationer behöver inga deploy keys.

Åtgärder i granskningsloggen: tenant.auth_policy.allow_repo_deploy_keys.enabled / .disabled (reglaget); tenant.auth_policy.deploy_key_violation (per aktiv nyckel medan policyn är av).

Kräv signerade commits

När detta är påslaget har standardbranchen i varje repo i organisationen en branch-skyddsregel som kräver signerade commits. Medlemmarna måste konfigurera signering av commits med GPG eller SSH på sina datorer; osignerade commits till standardbranchen avvisas av Forgejo vid push.

Inställningen gäller så fort du sparar den. fremforge börjar genast tillämpa den på organisationens befintliga repon, i bakgrunden, och raden under reglaget i Säkerhet › Policyer › Repo-regler visar förloppet och när det blev klart. En kontroll varje timme håller sedan varje standardbranch i linje, även för repon som skapas senare. Sparar du samma värde igen startar en ny kontroll.

Slår du av den stängs kravet av igen, också genast, på de regler som fremforge slog på för den här inställningen. En regel där en repoadministratör själv har krävt signerade commits lämnas som den är, och detsamma gäller resten av varje regel: godkännanden och statuskontroller rörs inte, och ingen regel tas bort. Har en administratör för hand kryssat i “require signed commits” igen på en regel som fremforge redan hade satt kan fremforge inte skilja de två åt; den regeln stängs av tillsammans med de andra, och administratören kan sätta den igen.

Det är en och samma inställning som standardvärdet för signerade commits i nya repon: när du sparar sätts båda, så ett nytt repo startar med samma krav (se Repo-regler).

Reglaget är organisationens golv: branch-skydd per repo gäller om de är satta.

Via API:et gör PATCH /orgs/{org}/auth-policy med require_signed_commits samma sak och svarar signed_commits_applying: true.

Så konfigurerar medlemmarna signering:

# 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".

Åtgärder i granskningsloggen: tenant.auth_policy.signed_commits.enabled / tenant.auth_policy.signed_commits.disabled (inställningen); tenant.auth_policy.signed_commits.applied / tenant.auth_policy.signed_commits.reverted (per reporegel som fremforge ändrade).

Tillåt SSH-protokollet

Det här reglaget styr om Git över SSH överhuvudtaget är tillåtet. Av (standard för organisationer som skapats efter 2026-05-22) betyder att varje Git-åtgärd över SSH mot organisationens repon avvisas: push, kloning och fetch, och även Git LFS över SSH. Kloning och fetch avvisas innan Git startar; en push avvisas i pre-receive-hooken. En avvisad kloning eller fetch visar ett meddelande som nämner den här inställningen och anger HTTPS-adressen att klona från i stället (se Vad en avvisad utvecklare ser). Medlemmarna använder HTTPS + Git Credential Manager, som kräver MFA via organisationens IdP vid varje förnyelse av token. Slå på reglaget för att tillåta SSH (det äldre standardvärdet före 2026-05-22).

Varför det här finns: IP-tillåtelselistan omfattar inte Git över SSH. SSH når fremforge via en lastbalanserare som ersätter källadressen med en av våra egna klusternoder, så den adress din utvecklare ansluter från syns inte för oss, och fremforge vägrar bedöma en anslutning utifrån en adress som vi vet är fel. Organisationer som vill att varje Git-åtgärd ska filtreras på IP stänger av SSH här och använder HTTPS, som tillåtelselistan omfattar.

Vad en avvisad utvecklare ser

En git clone eller git fetch över SSH mot ett repo i en organisation där SSH är avstängt misslyckas 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.

Utvecklarens SSH-nycklar och medlemskapet i organisationen rörs inte: slår du på reglaget igen återställs SSH-åtkomsten omedelbart.

Varje avvisning registreras i granskningsloggen som git.ssh.tenant_disabled_blocked, både för push och för kloning och fetch.

Åtgärder i granskningsloggen: tenant.auth_policy.ssh_disabled.enabled / tenant.auth_policy.ssh_disabled.disabled.

IP-tillåtelselista

IP-tillåtelselistan har flyttat till en egen sida: IP-tillåtelselista. En enda lista omfattar nu varje HTTPS-yta, så det finns inte längre något scope att välja. Förhandsläget med endast granskning, reglaget för runners och nödåtkomsten beskrivs där.

Lagringstid för granskningslogg

Styr hur länge granskningsloggens sökbara innehåll sparas. Den kryptografiska kedjan (3 års WORM) påverkas inte av inställningen; det är bara de läsbara kolumnerna actor + fields_json som berörs.

Inställningen tillämpas vid den dagliga maskeringskörningen (~02:30 UTC). Förlänger du fönstret förblir nyskrivna rader sökbara längre; förkortar du det maskeras rader äldre än det nya fönstret oåterkalleligt vid nästa körning. Se Granskningslogg → Lagringstid för alla detaljer.

Åtgärd i granskningsloggen: tenant.auth_policy.audit_retention.updated.

Så samverkar de

Vad som tillämpar vad

De här policyerna tillämpas i plattformslagret vid varje begäran. Administrationsgränssnittet är den auktoritativa källan för vad organisationen har valt.

Begränsningar

• Gränsen för PAT-livslängd gäller när en token utfärdas. Befintliga tokens förkortas INTE retroaktivt. Skärper du gränsen kommer en del bot- och CI-tokens att leva längre än den nya policyn; de fungerar fortfarande tills deras ursprungliga utgångsdatum.
• Kravet på hårdvarunycklar gäller bara NYA nycklar. Medlemmarna behåller sina befintliga nycklar.
• Signerade commits tillämpas på befintliga repon i bakgrunden när inställningen sparas; i en stor organisation tar det en minut eller två, och förloppet visas under reglaget. Nya repon som skapas efter att reglaget slagits på får regeln när de skapas.