I'm using Linux Mint, and have not been able to get gnome-keyring to unlock automatically at login, it seems.

A symptom of my problem is as follows:

$ ssh-add
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)

$ git pull
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-Nmf3J3/pkcs11: No such file or directory

How can I make it that git can push/pull without any passphrase input from me?

I realize there's several things here with gnome-keyring, and ssh-agent, but have not been able to nail it down.

Running ssh-add during a session means that I am no longer asked for my passphrase for SSH/git.

The problem is that I would need to run ssh-add during each session - I must be missing how to have Gnome's keyring unlock at login.

$ export | grep GNOME          

It happened again during the same session as the first edit. I did git pull and got WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-hjMM4V/pkcs11: No such file or directory.

$ env | grep SSH

$ ps -fp $SSH_AGENT_PID
eoin      2116  2038  0 09:47 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
  • 1
    Can you run export | grep GNOME and post the results. Have you seen this bug?
    – didster
    Commented Oct 28, 2012 at 22:08
  • Looks like a relevant bug. Since I don't always see the warning, I'm not sure if I have a simpler problem simply getting gnome-keyring to unlock automatically at login.
    – eoinoc
    Commented Oct 29, 2012 at 10:05
  • possibly you have another agent than gnome-keyring running. What about env | grep SSH and ps -fp $SSH_AGENT_PID Commented Oct 29, 2012 at 10:11
  • @StephaneChazelas I've added what you suggested, thanks. Yes, I have made life complex with zsh and tmux running (just to mention that).
    – eoinoc
    Commented Oct 29, 2012 at 10:53

4 Answers 4


What is meant to happen is:

You start a gnome session, part of that a gnome-keyring daemon (which also acts as a ssh agent) starts and the environment of anything started during that gnome session is updated with information on how to contact that ssh agent. The password you issue upon graphically logging in is used to unlock the default keyring.

When you use gnome-keyring as a ssh-agent, you don't want to use another agent like ssh-agent.

When your X session terminates, so does gnome-keyring. But your tmux session remains. Then, even if you start another gnome-keyring or ssh-agent, the environment of the processes already started by tmux won't be able to talk to it unless you update their environment with the path of the new socket.

What you could do is:

gnome-keyring-daemon -r > ~/.gkr

And do . ~/.gkr in all the shells you want to use the new gnome-keyring

Beware though of which DISPLAY that gnome-keyring-daemon is going to connect to.

  • Do you mean this is only for when my X session terminates, in other words whenever I log out and log back in again? I don't have .gkr, should I? How can I beware of which display that gnome-keyring-daemon is going to connect to?
    – eoinoc
    Commented Oct 29, 2012 at 17:39

The first thing I'd try is apt-get install ssh-askpass-gnome otherwise if you don't have that package (or some alternate askpass program) installed, then gnome can't prompt you for your password when you need to unlock your key.

You'll also need to have your DISPLAY variable set properly:

$ echo $DISPLAY

Also, how are you starting your terminal? There could be an issue with the way you are starting the terminal session and whether or not it inherits from gnome-session. This can happen when you use some gnon-gnome program to set your key bindings.

Presuming you use gnome-terminal you can check using pstree. Here you can see the correct inheritance happening:

$ pgrep gnome-terminal | xargs -l1 pstree -s 

Whereas in this session it is NOT inheriting from gnome-session:

$ pgrep gnome-terminal | xargs -l1 pstree -s 

Also, check that ssh-agent is being started by gnome-session:

$ pgrep ssh-agent | xargs -l1 pstree -s
  • It's a bit complicated about what terminal I'm using (my own fault!). My terminal launch command is mate-terminal --maximize -e tmux (which I presume is gnome-terminal). Furthermore, zsh is then loaded within tmux. ssh-askpass-gnome was installed. $DISPLAY has expected result. For the inheritance, tmux is sitting under mate-terminal with no mension of gnome-session. On a separate branch, it's tmux───zsh───xargs───pstree. To answer your last question, the output is: init───mdm───mdm───x-session-manag───ssh-agent. What do you think? Thanks.
    – eoinoc
    Commented Dec 29, 2012 at 19:33
  • well, presuming you use gnome (and I think Mint does by default, so unless you've changed it from the default?) then I think not having your mate-terminal inheriting from gnome-session is the problem. two questions: 1) what is the output of pgrep -fl gnome-session and; 2) what action do you take to actually invoke your terminal? from a menu? from a hot-key binding? or ????
    – aculich
    Commented Dec 29, 2012 at 22:07
  • Yes, I'm on Gnome. 1) Output is empty. 2) Very interesting. I usually do Ctrl+Alt+t. It's a shortcut I set using the Linux Mint application Keyboard Shortcuts using the command I previously mentioned. However, when launching Terminal through the main "Start" menu, SSH acted differently. The Gnome GUI prompted me for my password to my keyring. The option to save this passphrase for later sessions was greyed out, I couldn't select it. (The menu launcher command is also mate-terminal --maximize -e tmux.) Does that get us closer? Thanks, aculich.
    – eoinoc
    Commented Dec 30, 2012 at 7:08
  • If you're seeing the odd behavior with the Ctrl+Alt+t that you set in the Keyboard Shortcuts then I think you're probably experiencing a bug in mdm/MATE. What version of Mint are you running?
    – aculich
    Commented Dec 31, 2012 at 7:30
  • I'm one version behind, on Linux Mint 13. But for the menu-accessed terminal, why would it still not let me select "save this passphrase for each time I log in"?
    – eoinoc
    Commented Dec 31, 2012 at 12:08

I think problem on permanently storing password-protected SSH key.

Please have a look at the following resources:

  • I'll comment as I go. With the first link, I added ` IdentityFile ~/.ssh/id_rsa` to ~/.ssh/config but that didn't fix it.
    – eoinoc
    Commented Dec 29, 2012 at 19:06
  • The third link shows basic setup which doesn't seem to go further than what I've already done. Thanks, though.
    – eoinoc
    Commented Dec 29, 2012 at 19:23

Add this to your .bash_profile

if [ -n "$SSH_AUTH_SOCK" \
    -a "${SSH_AUTH_SOCK::13}" = "/tmp/keyring-" \
    -a ! -L "$SSH_AUTH_SOCK" ]
    eval `ssh-agent`
    ln -sfn "$SSH_AUTH_SOCK" "$OLD_AUTH_SOCK"
  • Thanks Mark. With this, $SSH_AUTH_SOCK has a value of /tmp/ssh-QCndYkdq2025/agent.2025. Am I missing something? $git pull still brings up SSH passphrase prompt.
    – eoinoc
    Commented Nov 3, 2012 at 12:34
  • Check your permissions on your .ssh/authorized_keys file on the server. It should be 0600.
    – Mark Cohen
    Commented Nov 3, 2012 at 18:16
  • On the server? GitHub is the external server, and my SSH key is recorded there. Isn't this more of a local issue, no?
    – eoinoc
    Commented Nov 4, 2012 at 14:55
  • Sorry, didn't realize you were using github. Yeah, you have no control over that host. You could add multiple keys to your ssh-agent and experiment sshing to localhost to make sure you can auth properly. Also, you can try ssh -vvv user@host and see what's breaking.
    – Mark Cohen
    Commented Nov 5, 2012 at 3:07
  • Most desktop Linux systems (Mint included) handle ssh-agent properly upon login right out of the box and it is usually roll-your-own things like this that break it. If for some reason your system doesn't handle ssh-agent, don't do it by hand. Instead use keychain which is well-designed to handle this and related problems. It also works for BSD (Mac) and other non-Linux systems.
    – aculich
    Commented Dec 28, 2012 at 9:01

You must log in to answer this question.

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