SSH ASKPASS helper used before 1Password is authenticated, causing manual passphrase prompts on every restart

[kylebrodeur]

Problem Summary

Every time the system restarts or a new shell session starts, the SSH key passphrase must be entered manually before 1Password is unlocked. Once 1Password is unlocked, the passphrase resolution works as expected, but the initial bootstrap sequence is broken.

Root Cause Analysis

1. setup_ssh_agent.sh does not verify op authentication before configuring SSH_ASKPASS

In src/setup_ssh_agent.sh:

if command -v op >/dev/null 2>&1 && [[ -f "$_askpass_helper" ]] && [[ -x "$_askpass_helper" ]]; then
  if ! grep -q "REPLACE/WITH/YOUR" "$_askpass_helper" 2>/dev/null; then
    export SSH_ASKPASS="$_askpass_helper"
    export SSH_ASKPASS_REQUIRE="prefer"
    _askpass_vars_set=true
  fi
fi

The script verifies that:

• op CLI is installed
• The askpass helper file exists and is executable
• The placeholder reference has been replaced

It does NOT verify that op is actually authenticated. On a fresh boot:

1. The 1Password desktop app is locked
2. There is no cached session token yet (or it has expired)
3. op vault list would fail with "not currently signed in"
4. Yet SSH_ASKPASS is still set to the 1Password helper

2. askpass-1password.sh fails silently when op is not authenticated

In src/askpass-1password.sh:

op read "$OP_SECRET_REFERENCE"

When op is not authenticated, op read fails and writes an error to stderr, but nothing (or an empty string) goes to stdout. ssh-add interprets this empty/failed output as the passphrase, which is incorrect. Because SSH_ASKPASS_REQUIRE=prefer (not force), ssh-add then falls back to a terminal prompt, forcing the user to type the passphrase manually.

3. op-session-manager.sh interactive signin may break in .zshrc

In src/op-session-manager.sh:

op signin > "$TOKEN_FILE"

This redirects stdout to the token file. If op signin outputs prompts to stdout (depending on auth method), the user may not see them in the .zshrc context, causing the signin to hang or fail silently.

4. SSH_ASKPASS and SSH_ASKPASS_REQUIRE are unset after keychain runs

if $_askpass_vars_set; then
  unset SSH_ASKPASS
  unset SSH_ASKPASS_REQUIRE
fi

This means even if a user later authenticates 1Password and wants to run ssh-add manually, the ASKPASS environment is gone and must be manually recreated.

Impact

• On every system restart / new login, the user sees a manual SSH passphrase prompt
• The whole value proposition of "1Password provides the passphrase automatically" is lost at the most critical moment
• The setup documentation explicitly states the session manager must come before SSH setup, but even with correct ordering, the SSH script does not gate on 1Password readiness

Reproduction Steps

1. Reboot the system (or open a fresh terminal with no existing ssh-agent)
2. Ensure 1Password desktop app is locked (or no OP_SERVICE_ACCOUNT_TOKEN is exported)
3. Open a new shell where .zshrc sources ~/.ssh/setup_ssh_agent.sh
4. Observe that keychain runs and ssh-add prompts for passphrase manually
5. Only after unlocking 1Password separately does op read work

Environment

• Linux/WSL/macOS with keychain installed
• 1Password CLI (op) installed
• SSH key with passphrase
• Desktop app integration or session token caching (not service account)

Suggested Fixes

Fix 1: Gate SSH_ASKPASS on 1Password authentication status

In setup_ssh_agent.sh, add an authentication check:

if command -v op >/dev/null 2>&1 && [[ -f "$_askpass_helper" ]] && [[ -x "$_askpass_helper" ]]; then
  if ! grep -q "REPLACE/WITH/YOUR" "$_askpass_helper" 2>/dev/null; then
    # NEW: Only use 1Password ASKPASS if op is actually authenticated
    if op vault list >/dev/null 2>&1; then
      export SSH_ASKPASS="$_askpass_helper"
      export SSH_ASKPASS_REQUIRE="prefer"
      _askpass_vars_set=true
    else
      if [[ -n "$OP_DEBUG" ]]; then
        echo "[DEBUG] 1Password not authenticated. Skipping ASKPASS config." >&2
      fi
    fi
  fi
fi

Fix 2: Add error handling to askpass-1password.sh

# Verify op is authenticated before trying to read
if ! op vault list >/dev/null 2>&1; then
  # Exit non-zero so ssh-add can fall back to terminal prompt
  echo "1Password not authenticated" >&2
  exit 1
fi

op read "$OP_SECRET_REFERENCE"

Fix 3: Consider not unsetting SSH_ASKPASS after keychain

Leaving SSH_ASKPASS in the environment allows manual ssh-add operations to also benefit from 1Password after the user authenticates. Alternatively, export a helper function or alias.

Fix 4: For op-session-manager.sh, ensure interactive prompts are visible

Consider using /dev/tty for op signin output when in an interactive shell, or use op signin --raw with explicit prompting, to avoid stdout redirection swallowing prompts:

op signin > "$TOKEN_FILE" 2>/dev/tty

---

Files Affected

• packages/1password-cli-tools/src/setup_ssh_agent.sh
• packages/1password-cli-tools/src/askpass-1password.sh
• packages/1password-cli-tools/src/op-session-manager.sh
• packages/1password-cli-tools/lib/config.js (.zshrc block generation)

Related Documentation

• SKILL.md - SSH Agent (Troubleshooting section mentions this exact symptom but the docs only suggest checking env vars, not fixing the auth check)
• docs/SETUP.md (Order of sourcing is documented correctly, but the scripts don't enforce the dependency)

[kylebrodeur]

Update: Fixes implemented in adb2eed

All four root causes identified in this issue have been addressed in commit adb2eed (included in v0.3.3). Here's a summary of what changed:

1. ✅ Gate SSH_ASKPASS on 1Password authentication status

File: packages/1password-cli-tools/src/setup_ssh_agent.sh

• SSH_ASKPASS is now only exported after op vault list succeeds.
• If 1Password is locked on a fresh restart, the script prompts for op signin before keychain runs, so the user sees a 1Password unlock prompt instead of a raw SSH passphrase prompt.
• Added OP_DEBUG logging at every decision point.

2. ✅ Self-healing askpass-1password.sh with explicit error handling

File: packages/1password-cli-tools/src/askpass-1password.sh

• Replaced silent failure with _ensure_op_authenticated() helper that:
  1. Checks if op is already authenticated.
  2. Falls back to a cached session token file.
  3. Falls back to interactive op signin via /dev/tty.
• If all methods fail, the script exits with code 1 and prints a clear error to stderr. No more empty-string passphrases.
• Added set -euo pipefail for robustness.

3. ✅ SSH_ASKPASS vars are no longer unset after keychain

File: packages/1password-cli-tools/src/setup_ssh_agent.sh

• The old unset SSH_ASKPASS / unset SSH_ASKPASS_REQUIRE block was removed.
• This means manual ssh-add or subsequent shells in the same session can still use the 1Password helper without recreating the environment.

4. ✅ op-session-manager.sh TTY guards and /dev/tty redirects

File: packages/1password-cli-tools/src/op-session-manager.sh

• Added a guard: if neither [[ -t 0 ]] nor [[ -r /dev/tty ]] is available, the script skips interactive signin and prints a warning (prevents hangs in headless / non-interactive contexts).
• op signin now redirects stdin from /dev/tty, so prompts are visible even when sourced from pipes, tmux reattach, or VS Code terminals.

Bonus changes

• SSH_ASKPASS_REQUIRE changed from 'prefer' → 'force' so ssh-add exclusively uses the helper and never falls back to a TTY passphrase prompt.
• Cached token path standardized to ~/.config/op-ssh/.op_session_token (shared between session manager, setup script, and askpass helper).
• Bumped pi-1password dependency pin on 1password-cli-tools to 0.3.3 (exact version).

---

Please test on your next restart / fresh shell session and report back. If the 1Password unlock prompt appears correctly before any SSH passphrase prompt, we can close this. If you still see issues, attach OP_DEBUG=1 output and I'll dig in.

Leaving the issue open until validated.