Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

Edit

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.

As requested by didster:

$ export | grep GNOME          
GNOME_KEYRING_CONTROL=/tmp/keyring-hjMM4V
GNOME_KEYRING_PID=1961

Edit 2

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.

As requested by Stephane:

$ env | grep SSH
SSH_AGENT_PID=2116
SSH_AUTH_SOCK=/tmp/ssh-OACxJMBY2038/agent.2038

$ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
eoin      2116  2038  0 09:47 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
share|improve this question
1  
Can you run export | grep GNOME and post the results. Have you seen this bug? –  didster Oct 28 '12 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 Oct 29 '12 at 10:05
    
possibly you have another agent than gnome-keyring running. What about env | grep SSH and ps -fp $SSH_AGENT_PID –  Stéphane Chazelas Oct 29 '12 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 Oct 29 '12 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.

share|improve this answer
    
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 Oct 29 '12 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
:0.0

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 
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───xmonad-x86_64-l(27139)───gnome-terminal(26036)─┬─bash(26041)
                                                                                                                 ├─gnome-pty-helpe(+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 └─{gnome-terminal}+

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

$ pgrep gnome-terminal | xargs -l1 pstree -s 
init(1)───sh(25919)───gnome-terminal(25920)─┬─bash(25927)
                                            ├─gnome-pty-helpe(25926)
                                            ├─{gnome-terminal}(25921)
                                            ├─{gnome-terminal}(25924)
                                            └─{gnome-terminal}(25928)

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

$ pgrep ssh-agent | xargs -l1 pstree -s
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───ssh-agent(27091)
share|improve this answer
    
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 Dec 29 '12 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 Dec 29 '12 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 Dec 30 '12 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 Dec 31 '12 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 Dec 31 '12 at 12:08

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

Please have a look at the following resources:

share|improve this answer
    
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 Dec 29 '12 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 Dec 29 '12 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" ]
then
    OLD_AUTH_SOCK="$SSH_AUTH_SOCK"
    eval `ssh-agent`
    mv "$OLD_AUTH_SOCK" "$OLD_AUTH_SOCK"~
    ln -sfn "$SSH_AUTH_SOCK" "$OLD_AUTH_SOCK"
    SSH_AUTH_SOCK="$OLD_AUTH_SOCK"
fi
share|improve this answer
    
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 Nov 3 '12 at 12:34
    
Check your permissions on your .ssh/authorized_keys file on the server. It should be 0600. –  Mark Cohen Nov 3 '12 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 Nov 4 '12 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 Nov 5 '12 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 Dec 28 '12 at 9:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.