I am storing various passwords (e.g. for remote email servers) in my keychain. From the command line, when logged in locally, I can retrieve these via:

security unlock-keychain ~/Library/Keychains/login.keychain
<enter password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com
<dumps keychain attributes, not including password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com -g
<dumps keychain attributes, including password>

However, the results cannot be achieved when run remotely (ssh'ing in to the box from somewhere else):

security unlock-keychain ~/Library/Keychains/login.keychain
<enter password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com
<dumps keychain attributes, not including password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com -g
<nothing printed, to stdout or stderr>

Moreover, the return value of the final command (using -g) is 36.

I've dumped the output of set from a local login and compared it to a remote one, and the missing environment variables are:


What am I missing? I do have SSH_AUTH_SOCK set to a valid value (returned from ssh-agent).


In reproducing this to investigate, I notice that I have my keychain configured to “Confirm before allowing access.” So when I perform the find-internet-password locally with the -g flag, I get a dialog box stating security wants to use your confidential information stored in “smtp.gmail.com” in your keychain. If I click “Allow” then it works, if I click “Deny” it fails similarly to the ssh case, with a return code of 51. Access confirmation dialog

When I try the command remotely via ssh, the -g immediately results in failure, with the status of 36 that you are reporting.

I suspect that this is because, when you ssh in, there is no way for the system to pop up a dialog box allowing you to confirm that you want to allow the security command to access this information.

I was able to get the command to work while connected by ssh by first clicking the “Always Allow” option when running the command locally. This updates the permissions in Keychain so that I no longer need to respond to the dialog (even locally), which allows it to work remotely too.

I don’t know if this will be entirely helpful to you, however, as I think it means you will need to preemptively grant the security program access to any keychain items you may want to access remotely. It may be possible to write a script to do this?

If you are experimenting with this manually and later want to revoke this access, you can go to the affected item in Keychain Access, choose Get Info and look at the Access Control tab. You will see an entry for security there, which you can delete: Access Control Dialog

| improve this answer | |
  • I've done the same thing -- added the 'security' command to the "always allow access" list (which is also done by clicking "Always allow" on the popup that appears when issuing the command locally), but I still cannot access the keychain item remotely thereafter. There must be another setting somewhere that needs to be altered, but I cannot find it. – Ether Mar 24 '15 at 22:50
  • 1
    ahahaha -- this does actually work, but one needs to log in with a new session after changing the settings in the Keychain for them to take effect. Hooray! (I'll add an answer to this question if I ever find out how to remotely alter the access privileges, but setting things up locally in advance for subsequent remote use is acceptable for now.) – Ether Mar 24 '15 at 23:11
  • 2
    Also note -- it's essential to also run security unlock-keychain ~/Library/Keychains/login.keychain in the remote session where you're trying to use the keychain. This will prompt for your password, so you can't do it in a script. There may be ways to achieve this without a password, but that's out of the scope of this question :) – Ether Mar 24 '15 at 23:57
  • does anyone know if I can enter the password in the command line for security unlock-keychain? – tofutim Sep 23 '16 at 19:06
  • 3
    @Ether If keychain is in default /Users/[user]/Library/Keychains/ path you can omit full path and go with just login.keychain. – solgar Jan 25 '17 at 17:17

security -i unlock-keychain

works for me in MacOS 10.13.4 High Sierra.

After investigating karthick's solution, I found this. The -i makes the command interactive and prompts you in the terminal for your password.

| improve this answer | |

As long as the security keychain is in the default location you can run the below command to unlock it. It does not prompt for a password. It worked remotely.

security unlock-keychain -p "enter password"

| improve this answer | |
  • Welcome to Ask Different! We're trying to find the best answers and those answers will provide supporting info as to why they're the best. Answers should be self-contained so explain why you think the answer you provided will solve the problem or is better than others out there. Providing links as supporting information can also help the OP, and others, find additional info for themselves. See How to Answer on how to provide a quality answer. - From Review – fsb Feb 22 '18 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .