It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
Forum Discussion
Former Member
3 years agossh agent does not list my keys despite $SSH_AUTH_SOCK set
I've seen previous discussions on this topic, https://1password.community/discussion/139077/ssh-agent-wont-list-my-keys, however my current configuration has all the bits in that discussion.
So, h...
jth
4 days agoOccasional Contributor
Waking a zombie thread on this topic. Welcome back! If anyone @ 1Password sees this, you have developer docs that need updating.
I've been having repeated issues where non-ssh clients like git and gcloud are not seeing or honoring configs in my ~/.ssh/config where I've declared IdentityAgent. Which is to say these clients were not correctly finding and using the 1Password SSH Agent, so SSH connections were simply timing out instead of correctly prompting me to authorize use of the SSH key.
Searching and troubleshooting eventually brought me here (<-- the page that needs fixing, 1P folks) where I found that if I define SSH_AUTH_SOCK, these apps all continue to behavore more as I expected. So I tried to follow those instructions to create a plist file to automatically set SSH_AUTH_SOCK since some utilities use that over the SSH config. But the plist file on that page is wrong.
The command that it is (trying to) run is:
ln -sf ~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock \$SSH_AUTH_SOCK But this plist fails to run successfully. LaunchAgents do not like to run things that run things, like open a shell to run a command, so it doesn't want to do this. After much troubleshooting, I did eventually convince this to run as intended by changing the program arguments to /bin/ln / -sf / ~/Lib...sock / $SSH_AUTH_SOCK.
This then brought me to the real issue, which is that this plist is trying to replace the agent.sock file with a symlink to itself, which is Not Right. What we want to do is to set the environment variable, not break the .sock file, which is similar to running:
export SSH_AUTH_SOCK=~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sockOn a commandline, this would normally just be dropped into a .bashrc, .zshrc, or /etc/profile.d/1password.sh file. But for any tools that aren't being started from a commandline, we need that environment variable set on login so it's existing in our macos login session (not just a bash or zsh session).
Here's what I have, which is working:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.1password.SSH_AUTH_SOCK</string>
<key>AssociatedBundleIdentifier</key>
<array>
<string>com.1password.1password</string>
</array>
<key>Program</key>
<string>/bin/launchctl</string>
<!--key>StandardErrorPath</key>
<string>/tmp/1password.launchagent.err</string>
<key>StandardOutPath</key>
<string>/tmp/1password.launchagent.out</string-->
<key>ProgramArguments</key>
<array>
<string>/bin/launchctl</string>
<string>setenv</string>
<string>SSH_AUTH_SOCK</string>
<string>~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock</string>
<!--string>\$SSH_AUTH_SOCK</string-->
</array>
<key>RunAtLoad</key>
<true />
</dict>
</plist>So there you go. And the commented out StandardErrorPath and StandardOutPath keys are left here for the betterment of the world - pretty handy to be able to go see what/whether is actually running when you try to load this with launchctl.