Session start

NAME

session-start - login to a signed commit

DESCRIPTION

One session end to end: a terminal opening, the key reaching the agent, tmux taking over, and the first commit that needs a signature. The setup runs two ways, Arch on the machine itself and Arch inside WSL, so this page calls them bare metal and WSL.

Contents

What runs, in order

What runs when a session starts Alacritty opens a shell, the profile sets SSH_AUTH_SOCK, the key arrives from 1Password on bare metal or from disk in WSL, tmux replaces the shell, and commits sign with the agent. The 1Password bridge answers only for keys kept in the vault. Alacritty a terminal opens a shell .bash_profile sets SSH_AUTH_SOCK Bare metal op-keys.service, at login reads the key and its passphrase out of 1Password WSL ~/.bashrc runs ssh-add on the copy kept on disk, so you type the passphrase once OpenSSH agent holds jdoe_id for the session exec tmux new-session a session per terminal, numbered from 0 git commit, ssh sign and connect with that key, no prompt 1Password bridge WSL only, for keys kept only in the vault prompts 1Password once per signature
  1. Alacritty opens a shell. A bare-metal machine starts bash from the Hyprland session it logged into. On Windows, Alacritty runs wsl.exe -d archlinux, and bash starts inside the distro.
  2. The profile names the agent. ~/.bash_profile points SSH_AUTH_SOCK at $XDG_RUNTIME_DIR/ssh-agent.socket and hands over to ~/.bashrc. The bare-metal machine made that export when tty1 started Hyprland, so each terminal inherits it.
  3. The key reaches the agent, by one of the two routes in the diagram. Either way the agent ends up holding jdoe_id for the session.
  4. tmux takes over. The last line of ~/.bashrc is exec tmux new-session, so a terminal opens session 0, then 1, and so on. Sessions already running are left alone.
  5. Commits and connections use the agent. git commit asks it for a signature, and ssh to git.jdoe-site.com or the server authenticates with the same key.

Where the key comes from

Where Source of the key What you type
Bare metal op-keys.service reads the Devices item at login nothing
WSL ~/.ssh/jdoe_id, which sits on disk the passphrase, once per session

A bare-metal machine reaches the passphrase through a service account token in ~/.config/op/token.env. WSL has no token, which is why its key sits on disk and its passphrase is typed.

WSL also runs the 1Password bridge, drawn dashed. It answers only for keys that exist in the vault and nowhere on disk, such as ppalms_github, and it asks 1Password for every signature. That prompt is why the local agent is the default, and why no routine work goes near the bridge.

When the agent is empty

ssh-add -l names what the agent holds. It should print one line ending in jdoe_id.

What you see What it means Do this
The agent has no identities. nothing is loaded Bare metal: op-keys. WSL: ssh-add ~/.ssh/jdoe_id, or open a new terminal
bad permissions on a .pub no agent holds the key, so ssh fell through to a file it cannot read fix the agent, not the file’s mode
Could not open a connection to your authentication agent SSH_AUTH_SOCK is unset or points at a socket that is gone systemctl --user start ssh-agent.socket, then a new shell
communication with agent failed the WSL bridge died, which an unanswered 1Password prompt causes eval "$(wsl2-ssh-agent)", then answer the prompt

SEE ALSO

The man pages index.