Tower Git client intermittently re-prompts for SSH key passphrase after macOS keychain changes

Answer the question first

The re‑prompting you’re seeing is almost never a Tower‑specific bug. Tower simply runs the system git binary, which in turn calls ssh. The only place that can decide when a passphrase is needed is the macOS ssh‑agent and the login keychain. If the agent can’t read the key from the keychain (because it’s locked, restarted, or the key was removed), ssh falls back to asking you for the passphrase.

Likely explanation

• Keychain lock or sync: iCloud Keychain sync, sleep, or a manual lock can temporarily make the key unavailable.
• Agent restart: After a macOS upgrade or a reboot, the system ssh‑agent starts before the login keychain is unlocked, so it can’t fetch the key.
• : If UseKeychain yes or AddKeysToAgent yes are missing for the key’s IdentityFile, the key is never stored in the agent.

Confirmed facts from the research

• Tower delegates all Git/SSH work to the system git binary; it has no internal key‑chain handling.
• macOS uses ssh‑agent integrated with the login keychain when UseKeychain yes is set in ~/.ssh/config.
• After macOS upgrades, the login keychain may be recreated or migrated, which removes the stored passphrase entry.
• Running ssh-add --apple-use-keychain ~/.ssh/id_ed25519 after each reboot or upgrade restores the key in the agent.

Diagnostic steps – which layer drops the key?

1. Verify Tower’s Git binary: Tower → Preferences → Git → Git Binary should point to /usr/bin/git (system) or /opt/homebrew/bin/git (Homebrew). If it points elsewhere, that binary may not honour the ~/.ssh/config.
2. Check the agent’s key list:

   ssh-add -l
   

   If your key is missing, it’s not loaded.
3. Verbose SSH test (replace [contact removed] with your host):

   ssh -vvv -T [contact removed] 2>&1 | grep -E '(keychain|agent|identity|Offering)'
   

   Look for lines like Offering public key: /Users/.../.ssh/id_ed25519 or sign_and_send_pubkey: no key in agent.
4. Inspect the keychain entry:

   security find-generic-password -s 'SSH: /Users//.ssh/id_ed25519'
   

   If the command fails, the passphrase is not stored.
5. After a macOS upgrade or reboot, re‑register the key:

   ssh-add --apple-use-keychain ~/.ssh/id_ed25519
   

   Then run ssh-add -l again to confirm.

Stable configuration that survives upgrades

• In ~/.ssh/config, add a block for each key:

  Host github.com
      IdentityFile ~/.ssh/id_ed25519
      UseKeychain yes
      AddKeysToAgent yes
  

• Keep the login keychain unlocked during work sessions:
  1. Open Keychain Access → login keychain → Edit → Change Settings for 'login'.
  2. Uncheck Lock after X minutes or set a long timeout.
• Optionally add ssh-add --apple-use-keychain ~/.ssh/id_ed25519 to a login‑item or ~/.bash_profile so it runs automatically after each login.
• In Tower, set GIT_SSH_COMMAND='ssh -vvv' under Preferences → Git → Environment Variables to get verbose logs if the problem re‑appears.

Ask for one missing diagnostic detail (if needed)

To fine‑tune the recommendation, could you confirm which SSH key(s) you’re using and whether UseKeychain yes is set for each in ~/.ssh/config? That detail determines whether the key is ever offered by ssh‑agent in the first place.