3

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
/usr/bin/ssh-add $(find $HOME/.ssh/keys -type f | egrep -v '\.pub$')

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?

3

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.

2
  • It feels like a bit of a hack, but it totally works! Thanks! 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
4

This is an old question, and probably deserves an updated answer. The following works for me (Fedora 31 / KDE).

  1. Set up KWallet with the default wallet (kdewallet) and with the same password as your login password. Ensure it unlocks on login. Arch Wiki has some info on that; in my case I had to uncomment some lines in /etc/pam.d/sddm.
  2. Create your SSH key (ssh-keygen) with whatever password you like (since you're going to use a password manager, it doesn't need to be memorable).
  3. Ensure ssh-add and ksshaskpass are installed.
  4. Add an auto-start script like the following:
    $ cat $HOME/.config/autostart-scripts/ssh
    #!/bin/sh
    SSH_ASKPASS=/usr/bin/ksshaskpass ssh-add </dev/null
    
    Do chmod +x and run it once. Ksshaskpass should ask your SSH password. Tell it to remember the password (this uses KWallet). Run again and notice this time it doesn't ask.

That should be it.

1

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

3
  • How does changing to zsh fix this problem? Mar 13 '14 at 20:52
  • @Michael, I fix my answer. Correct myself: zsh is one of the possible workarounds
    – dyomas
    Mar 14 '14 at 0:01
  • when using csh, use ssh-agent -c, from the man: Generate C-shell commands on stdout.
    – nbari
    Mar 11 '15 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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