Auth

Ollama uses a local SSH key for authentication. The private half lives in ~/.ollama/id_ed25519; the public half is uploaded to ollama.com when the user signs in. Handlers live across auth/ and server/auth.go.

Purpose

Avoid passwords. The local key signs requests to ollama.com, so the cloud knows the user without storing reusable credentials.

Key abstractions

Symbol	Location	Purpose
auth.GetPublicKey	auth/auth.go	Reads (or creates) the local SSH keypair.
auth.SignRequest	auth/auth.go	Signs an HTTP request with the local key.
Server.WhoamiHandler	server/auth.go	POST /api/me — returns the signed-in user from the cloud.
Server.SignoutHandler	server/auth.go	POST /api/signout and DELETE /api/user/keys/:encodedKey — removes the public key from the account.
signinURL	server/routes.go	Builds the URL the user opens in their browser to authorize the local key.
tui.RunSignIn	cmd/tui/signin.go	The CLI-side bubbletea sign-in flow.

How it works

sequenceDiagram
    participant CLI
    participant Daemon as ollama serve
    participant Browser
    participant Cloud as ollama.com

    CLI->>Daemon: ollama signin
    Daemon->>Daemon: read or create ~/.ollama/id_ed25519
    Daemon-->>CLI: signin URL with public key + hostname
    CLI->>Browser: open URL
    Browser->>Cloud: user logs in and authorizes key
    CLI->>Daemon: POST /api/me (after user confirms)
    Daemon->>Cloud: signed GET /api/me
    Cloud-->>Daemon: { name, email, ... }
    Daemon-->>CLI: user info

After sign-in, every request the daemon makes to the cloud (registry pulls/pushes, cloud-only inference, web search, web fetch) is signed with the same key.

Sign-in URL shape

signinURL (server/routes.go) returns:

https://ollama.com/connect?name=<hostname>&key=<base64 public key>

The hostname is local; the key is the SSH public key encoded for URL safety.

Sign-out

SignoutHandler deletes the public key from the user's account on ollama.com. The local key stays in place — signing in again on the same host does not create a new key, just re-uploads the existing one.

Integration points

• The cloud proxy (cloud-proxy) uses the signed key for every cloud request.
• The registry pull/push helpers in server/download.go and server/upload.go attach a signed Authorization header.
• Desktop app (app) shares the same key.

Entry points for modification

• Different key types → extend auth.GetPublicKey to handle additional algorithms.
• Different sign-in flow → change tui.RunSignIn and the signinURL shape, but keep the URL contract since the cloud side reads it.

Key source files

File	Purpose
auth/auth.go	Key generation, request signing.
server/auth.go	Sign-in/sign-out HTTP handlers.
server/routes.go	signinURL builder, route registration for /api/me, /api/signout.
cmd/tui/signin.go	TUI sign-in flow.