Take the 2-minute tour ×

I had this working once before, but for some reason it's not working on my new system.

in .kde4/Autostart/ I have a symlink to ssh-agent called 01-sshagent and then a simple script called 02-sshkeys that looks like this:

/usr/bin/ssh-add $(find $HOME/.ssh/keys -type f | egrep -v '\.pub$')

The problem seems to be that when I startup, ssh-agent is run alright, but KDE doesn't hold onto the output and store it in the environment, so for every Konsole session, I have to run ps to find the PID and then manually type:

SSH_AUTH_SOCK=/tmp/ssh-YtvdiEtW3065/agent.3065; export SSH_AUTH_SOCK;
SSH_AGENT_PID=<pidnumber>; export SSH_AGENT_PID;

...just to get it to work, and it does... just in that Konsole window.

I've tried removing the aforementioned symlink and just havining the ssh script look like this:

/usr/bin/ssh-agent | sh

But still, the agent variables aren't in the session and I'm never prompted for the password to my keys.

I'm obviously missing something, but what is it?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

My simple solution is to just run one ssh-agent and always keep it running. You can kill it on log-out if you really want to. The key is to just use a fixed socket. Add ssh-agent -a /tmp/$USER.agent to an Autostart script. Then do "export SSH_AUTH_SOCK=/tmp/$USER.agent" followed by ssh-add. Also, you can add that export to your .bashrc, .profile or other shell log-in script and always have access to the agent even when using a remote ssh in.

share|improve this answer
It feels like a bit of a hack, but it totally works! Thanks! –  Daniel Quinn Apr 1 '11 at 9:27
I started doing this once I realized it's not really less secure than running a per-session agent if I never really log out. The recommended way to use ssh-agent is not in Autostart, but use it kinda like sudo to run startkde. For example, "ssh-agent startkde" Before startkde runs, SSH_AUTH_SOCK is setup and when startkde exits, so does ssh-agent. It's more reliable than depending on Autostart, but trickier to set up correctly. Ubuntu has support to make this easy to do and will even generate a chain of commands like this. Looking at ps, I see "ssh-agent gpg-agent dbus-launch gnome-session" –  penguin359 Apr 1 '11 at 9:35

According to my observations quote "for some reason it's not working on my new system" stands:

  • while upgrade from Ubuntu 13.04 to 13.10 (new KDE version 4.11.5)
  • with shell tcsh

This happens with my favorite shell during aforementioned upgrade at least twice. Any other shells works fine. This problem has too scant internet coverage, because of tcsh low popularity. So, one of decisions is migrate to zsh. I do it

I dug deeper and found evident cause of error. ssh-agent started by command

eval $(ssh-agent)

in file /usr/share/upstart/sessions/ssh-agent.conf by upstart. First, command ssh-agent executad as is and produces output similar to:

setenv SSH_AUTH_SOCK /tmp/ssh-7AWho81toBZZ/agent.13776;
setenv SSH_AGENT_PID 13783;
echo Agent pid 13783;

Second, this output executed by eval and in case of csh we can see:

/proc/self/fd/9: 1: eval: setenv: not found

in ~/.cache/upstart/ssh-agent.log. This error is due "SHELL looks like csh style" (see ssh-agent(1)).

So, short and exhaustive answer is:

  • append -s option to ssh-agent invocation command (/usr/share/upstart/sessions/ssh-agent.conf):

    eval $(ssh-agent -s)

  • or do not use csh

share|improve this answer
How does changing to zsh fix this problem? –  Michael Hampton Mar 13 at 20:52
@Michael, I fix my answer. Correct myself: zsh is one of the possible workarounds –  dyomas Mar 14 at 0:01

Your Answer


