Enable gcr-ssh-agent by default so SSH keys work out of the box

[volfpeter]

What I hit

Fresh Omarchy 4.0.1 install, passphrase-protected ~/.ssh/id_ed25519. SSH auth to GitHub never worked without manual setup, and it fails in a fairly opaque way:

• SSH_AUTH_SOCK is unset in the session
• ssh-add -l → Could not open a connection to your authentication agent
• No SSH agent is enabled or reachable at all

Coming to Omarchy without an Arch background, this took a long time to work out. The relevant pieces are spread across systemd user units, a gnome-keyring split, and PAM, and none of it is discoverable from the symptom.

Why it's surprising

Omarchy already ships and configures most of what's needed:

• install/user/default-keyring.sh deliberately pre-creates a blank-password Default_keyring and makes it the default — an auto-unlocking secret store that matches autologin
• install/config/ssh-keepalive.sh ships opinionated SSH client defaults
• install/config/ssh-command-path.sh tunes the PAM PATH for SSH commands
• install/user/first-run/enable-user-units.sh already enables user systemd units at first run, and its comment explains why first-run is the right moment

But there are no references anywhere in /usr/share/omarchy to ssh-keygen, gcr-ssh-agent, or SSH_AUTH_SOCK. The secret store exists, the SSH client config exists, and the hook for enabling user units exists — but nothing ever makes an agent reachable.

Relevant background: gnome-keyring ≥ 42 dropped its own ssh component (it now runs --components=pkcs11,secrets). That role moved to gcr-ssh-agent, which ships in gcr-4 but is disabled by default on Arch.

Suggestion A — enable the agent (no prompts, helps everyone)

Two changes:

1. Add gcr-ssh-agent.socket to the list in install/user/first-run/enable-user-units.sh
2. Ship an environment.d drop-in with SSH_AUTH_SOCK=${XDG_RUNTIME_DIR}/gcr/ssh

This requires no user choice and helps anyone bringing an existing key. gcr-ssh-agent preloads ~/.ssh/*.pub and, on the first sign request for a key, runs ssh-add itself with the passphrase fetched from the keyring via libsecret. A passphrased key then unlocks silently — which is precisely what the blank-password Default_keyring is already there to enable.

I verified this end-to-end on my machine; it works with no other changes and no PAM edits.

One caveat worth designing for: 1Password's SSH agent sets its own SSH_AUTH_SOCK, and Omarchy already knows about 1Password (omarchy-system-lock locks it). Numbering the drop-in low (e.g. 10-ssh-agent.conf) keeps it overridable, since environment.d is read in lexical order.

Suggestion B — omarchy setup git ssh

omarchy setup security sshd --key=<pubkey> already covers the server side. The client side is missing. A command that generates ~/.ssh/id_ed25519 when absent, then either runs gh ssh-key add (when gh is available) or prints the public key, would close the last mile.

I'd suggest this as an omarchy setup ... command rather than an installer prompt: re-runnable, doesn't add to first boot, and stays forge-agnostic for GitLab/Gitea/Forgejo users.

On passphrases: if Omarchy ever generates a key, I'd suggest defaulting to no passphrase. With autologin plus a blank-password keyring plus LUKS, a passphrase stored in an unlocked keyring adds very little — the key and its passphrase end up side by side in the same home directory. It's worth an opt-in flag for people who disable autologin or sync keys into backups, but as a default it looks more protective than it is.

Naming note: install/user/first-run/setup-agent.hook already exists and refers to AI agents, so a new SSH command should avoid colliding with that name.

System

• Omarchy 4.0.1-1
• gnome-keyring 1:50.0-1, gcr-4 4.4.0.1-1, gcr 3.41.2-2, openssh 10.5p1-1
• SDDM autologin enabled, LUKS root

[lnnrthnng]

Yes please!