So I just upgraded my Mac mini (Late 2012) to macOS 10.12 (Sierra) and everything seems fine, but I’m running into one odd problem deploying code with Capistrano. I get the following error:
Permission denied (publickey).
Never had this problem before in Mac OS X 10.11 (El Capitan) or any version prior to it. Why is this suddenly happening now? Full output of the failed Capistrano deployment below:
jakes_mac:SomeCode jake$ cap staging deploy
INFO [hkdgad21] Running /usr/bin/env mkdir -p /tmp/somecode/ as jake@example.com
DEBUG [hkdgad21] Command: /usr/bin/env mkdir -p /tmp/somecode/
jake@example.com's password:
INFO [hkdgad21] Finished in 5.166 seconds with exit status 0 (successful).
DEBUG Uploading /tmp/somecode/git-ssh.sh 0.0%
INFO Uploading /tmp/somecode/git-ssh.sh 100.0%
INFO [xyz20312] Running /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh as jake@example.com
DEBUG [xyz20312] Command: /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh
INFO [xyz20312] Finished in 0.240 seconds with exit status 0 (successful).
INFO [abcdef01] Running /usr/bin/env git ls-remote --heads git@github.com:SomeUser/SomeCode.git as jake@example.com
DEBUG [abcdef01] Command: ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/somecode/git-ssh.sh /usr/bin/env git ls-remote --heads git@github.com:SomeUser/SomeCode.git )
DEBUG [abcdef01] Permission denied (publickey).
DEBUG [abcdef01] fatal: Could not read from remote repository.
DEBUG [abcdef01]
DEBUG [abcdef01] Please make sure you have the correct access rights
DEBUG [abcdef01] and the repository exists.
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as jake@example.com: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
SSHKit::Command::Failed: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Tasks: TOP => git:check
(See full trace by running task with --trace)
The deploy has failed with an error: Exception while executing as jake@example.com: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
This is due to a new feature in OpenSSH 7.2 causing a change in behavior on the part of the SSH client. From the release notes:
There were other interesting (security related) features introduced as well, although the release was considered mainly a bug fix release. This particular feature resulted in a default behavior change on OS X since it's default value is 'no' and OS X (I don't know about other clients) previously added keys to the agent as they were used.
So if you add the following to your
~/.ssh/config
file (or the globalssh_config
that should be located in/etc/ssh/ssh_config
), keys will again be added to your agent as they are used.This one-liner makes it pretty easy:
After doing this, I was able to achieve the expected behavior:
This help me to resolve the issue on MacOS Serra:
Seems like it’s an issue with SSH keys not being automatically added as it used to be in Mac OS X 10.11 (El Capitan). Is this expected behavior from macOS Sierra or something connected to OpenSSH?
Method 1: Add all known keys to the SSH agent.
So one solution I found is to run
ssh-add
with the-A
option—which adds all known identities to the SSH agent using any passphrases stored in your keychain—like this:Now this works but it won’t persist across reboots. So if you want to never worry about this again, just open up your user’s
~/.bash_profile
file like this:And add this line to the bottom:
Now when you open a new Terminal window, all should be good!
Method 2: Add only SSH keys that are in the keychain to the agent.
So while the
ssh-add -A
option should work for most basic cases, I ran into an issue recently where I had 6-7 Vagrant boxes (which uses SSH keys/identities for access) setup on a machine on top of the more commonid_rsa.pub
in place.Long story short, I ended up being locked out of a remote server due to too many failed tries based on SSH keys/identities since the server access was based on a password and SSH keys/identities are SSH keys/identities. So the SSH agent tried all of my SSH keys, failed and I couldn’t even get to the password prompt.
The problem is that
ssh-add -A
will just arbitrarily add every single SSH key/identity you have to the agent even if it’s not necessary to do so; such as in the case of Vagrant boxes.My solution after much testing was as follows.
First, if you have more SSH keys/identities added to your agent than you need—as shown with
ssh-add -l
then purge them all from the agent like so:With that done, then start the SSH agent as a background process like so:
Now, it gets weird and I am not too sure why. In some cases you can specifically add the
~/.ssh/id_rsa.pub
key/identity to the agent like so:Type in your passphrase, hit Return and you should be good to go.
But in other cases simply running this is enough to get the key/identity added:
If that’s all worked, type in
ssh-add -l
and you should see one lone SSH key/identity listed.All good? Now open up your
.bash_profile
:And add this line to the bottom; comment or remove the
-A
version if you have that in place:That will allow the SSH key/identity to be reloaded to the SSH agent on each startup/reboot.
UPDATE 1: Based on davidalger’s answer I discovered a nicer, global solution that can work for all user’s on a system. Just open up the global SSH config located here via
sudo
:And add this line to the bottom of the file:
Did that—after removing the
.bash_profile
fix and all is good as well.UPDATE 2: Apple has now added a
UseKeychain
option to the open SSH config options and considersssh-add -A
a solution as well.As of macOS Sierra 10.12.2, Apple (I assume) has added a
UseKeychain
config option for SSH configs. Checking the man page (viaman ssh_config
) shows the following info:Which boils down to Apple seeing the solution as either adding
ssh-add -A
to your.bash_profile
as explained in this Open Radar ticket or addingUseKeychain
as one of the options in a per user~/.ssh/config
.