Säker inloggning

Det rekommenderade sättet för utvecklare att logga in med Git är HTTPS + Git Credential Manager (GCM): interaktiv inloggning via organisationens IdP med MFA varje gång token förnyas. SSH är avstängt som standard för nya fremforge-organisationer; erfarna utvecklare som verkligen behöver SSH kan be organisationens administratör att slå på det igen. Den här sidan beskriver GCM-konfigurationen för macOS, Linux och Windows, plus ett avsnitt om reservvägarna SSH och PAT.

Varför HTTPS + GCM är standard

GCM är Microsofts hjälpprogram för inloggningsuppgifter med öppen källkod; fremforge integrerar med det via Forgejos inbyggda OAuth2-leverantör. Fungerar på utvecklardatorer med Windows, macOS och Linux.

HTTPS + Git Credential Manager (rekommenderas)

Steg 1: installera 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)

Steg 2: konfigurera GCM för fremforge

Kör detta en gång per arbetsstation:

# 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 är den inbyggda klienten git-credential-manager som följer med Forgejo, så ingen registrering per instans behövs; samma klient-id fungerar mot alla fremforge-instanser och alla Git-värdar byggda på Forgejo. Klienten använder PKCE (Proof Key for Code Exchange), så ingen client_secret behövs på utvecklarens dator. Loopback-anropen (http://127.0.0.1, http://localhost) accepteras på valfri port enligt RFC 8252 §7.3.

Steg 3: klona över HTTPS

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

GCM öppnar en flik i webbläsaren → frem.sh frågar efter din mejladress (så att vi vet vilken organisation du tillhör) → skickar dig till organisationens egen inloggningssida → bara din organisations IdP-knapp(ar) visas → ange lösenord + MFA hos din IdP → webbläsaren går tillbaka till GCM → token sparas. Andra kunders IdP:er syns aldrig. Följande clone, fetch och push under tokens livslängd sker tyst.

Åtkomsttoken gäller i 24 timmar, och inom det fönstret sker varje git push tyst. Uppdateringstoken gäller i 30 dagar, så nästa push efter att åtkomsttoken har gått ut förnyar den utan att webbläsaren öppnas. Varje dator du loggar in från behåller sin egen fungerande inloggning, så om du använder git både på en laptop och en stationär dator (eller i WSL) behöver ingen av dem logga in igen. Efter 30 dagar utan push eller fetch öppnar nästa operation webbläsaren igen, och MFA krävs via din IdP.

När GCM öppnar webbläsaren för att logga in på nytt (en ny enhet, efter att du har loggat ut eller efter 30 dagar utan användning) ber frem.sh dig först bekräfta att det är du med din autentiseringsapp eller säkerhetsnyckel. Det sker ungefär en gång i månaden på varje enhet; när inloggningen förnyas i bakgrunden får du aldrig frågan. Se Varför ombeds jag bekräfta att det är jag?

Steg 4: valfritt, ställ in rimliga standardvärden

# 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

Reservvägar

Personlig åtkomsttoken (endast CI-bottar och skript)

PAT:ar är statiska bearer-uppgifter utan MFA. De passar för obevakad automatisering, men aldrig för push av människor.

# 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-token från Forgejo Actions (arbetslastidentitet i CI, inga statiska uppgifter)

För CI/CD som driftsätter till AWS, Azure, GCP eller T Cloud Public bör du använda federerad identitet i stället för PAT:ar. fremforge ger CI-jobb kortlivade OIDC-token från sin runner-OIDC-utfärdare, https://frem.sh/_app/runner/oidc (discovery på https://frem.sh/_app/runner/oidc/.well-known/openid-configuration); konfigurera molnleverantörens IAM att lita på den utfärdaren. Claims (sub, aud, repository_owner) står på sidan nedan. Se Runner OIDC för mallar för förtroendepolicyer per moln.

SSH (bara när organisationens administratör uttryckligen har slagit på det)

Nya fremforge-organisationer har SSH avstängt som standard. Om din organisation behöver SSH (äldre CI, starka önskemål från utvecklarna om SSH-nyckelflödet):

1. Organisationens administratör går till <your-org>/_admin/auth-policy och markerar ”Tillåt SSH-protokollet”, och accepterar därmed den dokumenterade begränsningen att IP-tillåtelselistan inte gäller för SSH.
2. Medlemmarna lägger till SSH-nycklar på frem.sh/user/settings/keys och konfigurerar sin ~/.ssh/config:

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

3. Använd hårdvarubaserade nycklar där det går (ssh-add --apple-use-keychain på macOS för Touch ID; ssh-keygen -t ed25519-sk för FIDO/YubiKey på Linux). Se avsnittet om hårdvarubaserad SSH nedan.

Egna OAuth-applikationer: begär uttryckliga scopes

Om du registrerar en OAuth2-applikation på frem.sh (Användar- eller organisationsinställningar › Applikationer) för att logga in personer eller anropa API:t åt dem, kan dess token bara göra det som de begärda scopes tillåter:

• API-scopes (read:repository, write:issue, read:user och övriga): token fungerar mot API:t och mot Git över HTTPS inom de scopes, som tidigare.
• Bara openid, profile, email, groups: token loggar in personen och inget annat. Den fungerar mot /login/oauth/userinfo och /login/oauth/introspect och får 401 från API:t, paketregistren och Git.
• Inga scopes alls: samma sak, bara inloggning. Endast fremforges egna klienter (Git Credential Manager konfigurerad enligt ovan och CLI:t fremforge) behåller full åtkomst utan scope.

En applikation som behöver API:t måste alltså begära de API-scopes den behöver i parametern scope till /login/oauth/authorize. Om den redan har ett godkännande med ett annat scope återkallar personen det under Auktoriserade OAuth2-appar på frem.sh/user/settings/applications och loggar in igen.

Hårdvarubaserade SSH-nycklar (för organisationer som har slagit på SSH igen)

Om organisationens administratör har slagit på SSH igen och du verkligen behöver använda det, är hårdvarubaserade nycklar i praktiken obligatoriska. Organisationspolicyn ”Kräv hårdvarubaserade SSH-nycklar” avvisar redan vid registreringen varje nyckel som inte tillhör algoritmfamiljen 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 frågar vid varje push om macOS-nyckelringen inte nyligen har låst upp nyckeln. För ren Secure Enclave-lagring (nyckeln genereras och förvaras helt i chipet), använd Secretive.

Linux: YubiKey/FIDO-autentiserare

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+ (februari 2020) för ed25519-sk; ecdsa-sk är reservalternativet på äldre distributioner.

Windows: TPM-baserat via WSL2/KeePassXC

Windows inbyggda OpenSSH exponerar inte TPM direkt. Två vägar:

1. WSL2: följ Linux-flödet inuti WSL2.
2. SSH-agenten i KeePassXC eller 1Password: båda förvarar nycklar som skyddas med biometri via Windows Hello.

Beslutsträd

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

Det här ska du INTE göra

• Långlivade PAT:ar i git-konfigurationsfiler/.netrc. Statiska bearer-uppgifter utan utgångsdatum är det sämsta autentiseringsmönstret. Använd GCM för människor, OIDC-token för CI och PAT:ar med kort giltighetstid för äldre bottar.
• En vanlig ssh-keygen -t ed25519 utan hårdvarustöd eller krav från organisationen. Nyckeln ligger i ~/.ssh/; en borttappad laptop betyder en röjd nyckel under hela nyckelns livstid.
• Att kringgå MFA med mönster som ”lita alltid på SSH-nyckeln”. Om din organisation behöver styrning i klass med en IP-tillåtelselista betyder det HTTPS: fremforges IP-tillåtelselista tillämpas i realtid på HTTPS och är inte möjlig i arkitekturen för SSH.
• Att slå på SSH igen för att ”det går snabbare”. Skillnaden i konfigurationsbesvär är försumbar efter första dagen; skillnaden i säkerhet är verklig.

Referens för organisationens administratör

Om du är ägare av organisationen och ställer in policyer:

• Administrationsguide för autentiseringspolicy: reglaget för att stänga av SSH, krav på hårdvarubaserade SSH-nycklar, SSH-certifikatutfärdare (inbakad 2026-05-26), maximal livslängd för PAT, reglaget Tillåt deploy keys på repon, signerade commits, omfattning för IP-tillåtelselistan + förhandsvisning med enbart granskning