Double check your permissions in those files, if they are not like this, it won’t work:
-rw------- 1 martin staff 1675 Jul 27 2009 id_rsa
-rw-r--r-- 1 martin staff 403 Jul 27 2009 id_rsa.pub
UPDATE:
If you see that the files have an @, that means they have “extended attributes”.
You can see what they are by issuing:
xattr -l <filename>
Automatically Added Keys
There are three ways SSH keys are added to ssh-agent in Snow
Leopard.
- manually, with ssh-add,
- automatically, by ssh when you supply a key’s passphrase via
the GUI prompt, and
- automatically, by ssh-agent when it first starts.
The last two methods are Apple extensions: there are no “automatic”
additions with stock OpenSSH. All references to ssh, ssh-agent,
and ssh-add below are to Apple’s Snow Leopard versions unless
I prefix the program name with the adjective “stock”.
You can disable all of Apple’s keychain-oriented SSH modifications
with a (undocumented?) preference setting:
defaults write org.openbsd.openssh KeychainIntegration -bool false
Keys Added Automatically By ssh
(This is the part I missed in the previous version of my original
answer since I usually use a “stock” ssh.)
Whenever ssh tries to use a passphrase protected SSH key to
authenticate itself to a remote host, it will issue a GUI prompt for
the SSH key’s password. The key is also loaded into the agent (if
the passphrase is correct) whether or not you mark the “Remember
password in my keychain” checkbox.
There are two (undocumented?) ways to prevent ssh from issuing
this GUI prompt (and thus adding the SSH key to the ssh-agent):
A preference setting:
defaults write org.openbsd.openssh AskPassGUI -bool false
An
ssh_config
entry (or -o
option to ssh) that specifies AskPassGUI no
.
(see keychain_read_passphrase
in
keychain.c
;
the oAskPassGUI
parameter comes from the AskPassGUI
configuration setting)
When AskPassGUI
is disabled, ssh will prompt you in the normal
way for the key’s password (i.e. through the tty).
You could also avoid automatic adds from ssh by using a “stock”
ssh (e.g. OpenSSH compiled by
MacPorts,
Homebrew “duplicates” from
homebrew-alt, or
Fink).
Keys Added Automatically By ssh-agent
The keys that ssh-agent automatically adds are those that have
their passphrases stored in a keychain.
These “remembered keys” are automatically added when a new
ssh-agent starts.
There is no command line or configuration option (other than
KeychainIntegration
, described above) to prevent ssh-agent from
automatically loading the “remembered keys” (see the call to
process_add_from_keychain
(defined in
keychain.c
) from main
in
ssh-agent.c
).
If, however, you can arrange to lock the keychains that store your
SSH key passphrases, you can click Cancel when ssh-agent asks to
unlock the keychain(s) and effectively get ssh-agent to skip
adding these “remembered keys” when it first starts.
If there is no ssh-agent running, your first use of ssh will
likely trigger launchd to start an ssh-agent which will load all
the “remembered keys”. This makes it seem like ssh is loading the
keys into the agent, but it is really the agent itself that is
loading the keys. It only does this automatically when it first
starts.
The -k
option of ssh-add provides a manual way to add the
“remembered keys” (see add_from_keychain
in
ssh-add.c
which ends up as a message to the agent which calls
process_add_from_keychain
from process_message
in
ssh-agent.c
).
launchd Configuration
You are right that a system update could overwrite your modification to the file in /System/Library/LaunchAgents/
. You should always avoid changing things under /System/
; most things can be (re)configured without making changes there. In this case, it looks like you should be able to override the system default launchd job specification on a per-user basis with a file in ~/Library/LaunchAgents/
.
From what I can tell1, entries are loaded in this order2:
~/Library/LaunchAgents/
/Library/LaunchAgents/
/Network/Library/LaunchAgents/
(not present on most systems)
/System/Library/LaunchAgents/
It does not seem to be documented, but only the first job configuration for each Label (e.g. org.openbsd.ssh-agent
) will be kept. Any configuration from a later directory with the same Label as a configuration from an earlier directory is effectively skipped.
1
See
NSStartSearchPathEnumeration
used in launchctl.c
and defined in
NSSystemDirectories.h
/NSSystemDirectories.c
.
2
launchd also looks in the LaunchDaemons/
directories next to the various LaunchAgents/
directories for other types of jobs.
Best Answer
So, I managed to find a hacky solution that achieves the same goal. It appears (???) impossible to overwrite
SSH_AUTH_SOCK
, and I can't disable the builtin agent because I want to preserve SIP.However, I can abuse symlinking to get my agent working reliably. Thanks to a nice article explaining how to leverage the YubiKey on a Mac (similar to my goal), I managed to create a
LaunchAgent
to symlink my agent to whereverSSH_AUTH_SOCK
is pointing. So far I have yet to perform heavy testing with this, but it seems to be working okay.Just in case the source link goes down, I created a file at
~/Library/LaunchAgents/link-ssh-auth-sock.plist
with the following contents:This LaunchAgent replaces the Apple-generated socket (located in
/private/tmp/...
) with my own, but preserves Apple's environment variable. The symlink works, and is picked up in any application that supports using native SSH (in my case, PyCharm).It's not a true solution to the issue (the socket is being symlinked, who knows what issues this could cause), but it at least works for the time being.
I'll keep trying to find a true solution to this problem, but in the meantime I'll share this answer just for any other curious souls with the same issue.