Sikker innlogging

Den anbefalte måten for utviklere å logge inn med Git på er HTTPS + Git Credential Manager (GCM): interaktiv innlogging gjennom organisasjonens IdP, med MFA hver gang tokenet fornyes. SSH er slått av som standard i nye fremforge-organisasjoner; erfarne utviklere som virkelig trenger SSH, kan be administratoren i organisasjonen om å slå det på igjen. Denne siden dekker GCM-oppsettet for macOS, Linux og Windows, og har en egen del om reserveløsningene SSH og PAT.

Hvorfor HTTPS + GCM er standard

GCM er Microsofts credential helper med åpen kildekode; fremforge integrerer med den via Forgejos innebygde OAuth2-leverandør. Fungerer på arbeidsstasjoner med Windows, macOS og Linux.

HTTPS + Git Credential Manager (anbefalt)

Trinn 1: installer 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)

Trinn 2: konfigurer GCM for fremforge

Kjør dette én gang per arbeidsstasjon:

# 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-applikasjonen er den innebygde klienten git-credential-manager som følger med Forgejo. Den trenger ingen registrering per instans; den samme klient-ID-en fungerer mot alle fremforge-instanser og alle Git-verter basert på Forgejo. Klienten bruker PKCE (Proof Key for Code Exchange), så det trengs ingen client_secret på utviklerens maskin. Loopback-tilbakekallene (http://127.0.0.1, http://localhost) godtas på hvilken som helst port i henhold til RFC 8252 §7.3.

Trinn 3: klon over HTTPS

git clone https://frem.sh/<your-org>/<your-repo>.git

GCM åpner en fane i nettleseren → frem.sh ber om e-postadressen din (slik at vi vet hvilken organisasjon du hører til) → du sendes til organisasjonens egen innloggingsside → bare din organisasjons IdP-knapp(er) vises → skriv inn passord + MFA hos IdP-en din → nettleseren går tilbake til GCM → tokenet lagres. Andre organisasjoners IdP-er er aldri synlige. Senere clone, fetch og push innenfor tokenets levetid skjer i det stille.

Tilgangstokener varer i 24 timer, og innenfor det tidsrommet skjer hver git push i det stille. Oppdateringstokener varer i 30 dager, så neste push etter at tilgangstokenet har utløpt, fornyer det uten å åpne nettleseren. Hver maskin du logger inn fra, beholder sin egen gyldige innlogging, så bruk av git på en bærbar og en stasjonær PC (eller i WSL) gjør ikke at noen av dem må logge inn på nytt. Etter 30 dager uten push eller fetch åpnes nettleseren igjen ved neste operasjon, og MFA kreves via IdP-en din.

Når GCM åpner nettleseren for å logge inn på nytt (en ny enhet, etter at du har logget ut, eller etter 30 dager uten bruk), ber frem.sh deg først bekrefte at det er deg, med autentiseringsappen eller sikkerhetsnøkkelen din. Det skjer omtrent én gang i måneden på hver enhet; når innloggingen fornyes i bakgrunnen, blir du aldri spurt. Se Hvorfor blir jeg bedt om å bekrefte at det er meg?

Trinn 4 (valgfritt): angi fornuftige standardinnstillinger

# 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

Personlig tilgangstoken (bare for CI-boter og skript)

PAT-er er statisk bearer-legitimasjon uten MFA. De passer fint til automatisering uten tilsyn, men aldri 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-tokener fra Forgejo Actions (arbeidslastidentitet for CI, ingen statisk legitimasjon)

For CI/CD som ruller ut til AWS / Azure / GCP / T Cloud Public, bør du bruke føderert identitet i stedet for PAT-er. fremforge gir CI-jobber kortlevde OIDC-tokener fra sin runner-OIDC-utsteder, https://frem.sh/_app/runner/oidc (discovery på https://frem.sh/_app/runner/oidc/.well-known/openid-configuration); konfigurer IAM hos skyleverandøren din til å stole på den utstederen. Claimene (sub, aud, repository_owner) står på siden nedenfor. Se Runner OIDC for maler for tillitspolicyer per sky.

SSH (bare når administratoren i organisasjonen uttrykkelig har slått det på)

Nye fremforge-organisasjoner har SSH slått av som standard. Hvis organisasjonen din trenger SSH (eldre CI, sterk preferanse blant utviklerne for SSH-nøkler):

1. Administratoren går til <your-org>/_admin/auth-policy og setter hake ved «Allow SSH protocol», og godtar dermed den dokumenterte begrensningen at IP-tillatelseslisten ikke gjelder for SSH.
2. Medlemmene legger til SSH-nøkler på frem.sh/user/settings/keys og konfigurerer ~/.ssh/config:

Host frem.sh
    Hostname ssh.frem.sh
    Port 443
    IdentityFile ~/.ssh/id_ed25519

3. Bruk maskinvarebaserte nøkler der det er mulig (ssh-add --apple-use-keychain på macOS for Touch ID; ssh-keygen -t ed25519-sk for FIDO/YubiKey på Linux). Se delen om maskinvarebaserte SSH-nøkler nedenfor.

Dine egne OAuth-applikasjoner: be om eksplisitte scopes

Hvis du registrerer en OAuth2-applikasjon på frem.sh (innstillinger for bruker eller organisasjon › Applikasjoner) for å logge inn personer eller kalle API-et på deres vegne, kan tokenet bare gjøre det som scopene applikasjonen ba om, tillater:

• API-scopes (read:repository, write:issue, read:user og resten): tokenet fungerer mot API-et og mot Git over HTTPS innenfor disse scopene, som før.
• Bare openid, profile, email, groups: tokenet logger inn personen og ingenting annet. Det fungerer mot /login/oauth/userinfo og /login/oauth/introspect, og får 401 mot API-et, pakkeregistrene og Git.
• Ingen scope i det hele tatt: det samme, bare innlogging. Bare fremforges egne klienter (Git Credential Manager konfigurert som ovenfor og fremforge-CLI-et) beholder full tilgang uten scope.

En applikasjon som trenger API-et, må derfor be om de API-scopene den trenger, i parameteren scope til /login/oauth/authorize. Hvis den allerede har en tillatelse med et annet scope, tilbakekaller personen den tillatelsen under Autoriserte OAuth2-applikasjoner på frem.sh/user/settings/applications og logger inn på nytt.

Maskinvarebaserte SSH-nøkler (for organisasjoner som har slått på SSH igjen)

Hvis administratoren i organisasjonen din har slått på SSH igjen og du faktisk trenger det, er maskinvarebaserte nøkler beste praksis du bør regne som obligatorisk. Organisasjonspolicyen «Require hardware-backed SSH keys» avviser ved registrering enhver nøkkel som ikke tilhører algoritmefamilien sk-*.

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ør ved hver push hvis nøkkelringen i macOS ikke nylig har låst opp nøkkelen. For ren Secure Enclave-lagring (nøkkelen genereres og ligger helt inne i brikken) kan du bruke Secretive.

Linux: YubiKey / FIDO-autentisering

ssh-keygen -t ed25519-sk -C "your-name@your-org" -f ~/.ssh/id_ed25519_sk
ssh-add ~/.ssh/id_ed25519_sk

Krever OpenSSH 8.2+ (februar 2020) for ed25519-sk; ecdsa-sk er alternativet på eldre distribusjoner.

Windows: TPM-basert via WSL2 / KeePassXC

Innebygd OpenSSH i Windows gir ikke direkte tilgang til TPM-en. To veier:

1. WSL2: følg Linux-framgangsmåten inne i WSL2.
2. KeePassXC / 1Password SSH-agent: begge holder nøkler beskyttet av biometri i Windows Hello.

Beslutningstre

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

Dette bør du IKKE gjøre

• Langlivede PAT-er i git-konfigurasjonsfiler / .netrc. Statisk bearer-legitimasjon uten utløpstid er det verste autentiseringsmønsteret. Bruk GCM for mennesker, OIDC-tokener for CI og PAT-er med kort utløpstid for eldre boter.
• Vanlig ssh-keygen -t ed25519 uten maskinvarestøtte eller krav fra organisasjonen. Nøkkelen ligger i ~/.ssh/; en mistet bærbar PC betyr en kompromittert nøkkel så lenge nøkkelen lever.
• Å omgå MFA med mønstre som «stol alltid på SSH-nøkkelen». Hvis organisasjonen din trenger håndheving på nivå med en IP-tillatelsesliste, betyr det HTTPS: fremforges IP-tillatelsesliste håndheves i sanntid over HTTPS og er ikke mulig i arkitekturen over SSH.
• Å slå på SSH igjen fordi «det går raskere». Forskjellen i oppsettsfriksjon er ubetydelig etter første dag; forskjellen i sikkerhetsnivå er reell.

Referanse for administratorer

Hvis du er eier av en organisasjon og setter policy:

• Administrasjonsveiledning for autentiseringspolicy: bryter for å slå av SSH, krav om maskinvarebaserte SSH-nøkler, SSH-sertifikatutsteder (lagt inn her 2026-05-26), maksimal levetid for PAT-er, bryteren allow repo deploy keys, signerte commits, omfang for IP-tillatelseslisten + forhåndsvisning i ren revisjonsmodus