I set up a new user account for a friend on Kubuntu 12.04. When he uses ssh he gets this error:

Could not open a connection to your authentication agent

We're running ssh in some bash scripts.

After looking around at the wide variety of things that can lead to that error, I came across this solution:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Then he can run the ssh commands (and bash scripts) as expected.

Before running those two commands, the env variables are not set in a terminal:




After running the commands, the env variables are set as expected. However, they do not stay set (e.g., in a different shell or after rebooting).

I want to know how to set up his computer so he doesn't have to run those two commands to set the env variables. I do not need to run them on my computer (ever). So far I am not seeing what is different between our machines.

I see this info in the man page, but it does not tell me how Ubuntu is normally setting up the agent automatically or what is happening on my friend's machine so that this is not working for him.

There are two main ways to get an agent set up: The first is that the agent starts a new subcommand into which some environment variables are exported, eg ssh-agent xterm &. The second is that the agent prints the needed shell commands (either sh(1) or csh(1) syntax can be generated) which can be evalled in the calling shell, eg eval ssh-agent -s for Bourne-type shells such as sh(1) or ksh(1) and eval ssh-agent -c for csh(1) and derivatives.

After installing acct and rebooting, this is the output of lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

From the man page:

F -- command executed after a fork but without a following exec

I'm not sure if that is significant.

  • 2
    Under Ubuntu, ssh-agent is normally started from /etc/X11/Xsession.d/90x11-common_ssh-agent. This can be suppressed by removing use-ssh-agent from /etc/X11/Xsession. Are those files correct? Is the agent started and then killed or never started? (Install acct and run lastcomm after logging in to see what programs were lauched.) Aug 9, 2013 at 0:31
  • @Gilles-thank you. Those two files are identical on my machine and his machine. We both have X11/Xsession.options:use-ssh-agent and X11/Xsession.d/90x11-common_ssh-agent:SSHAGENT=/usr/bin/ssh-agent. I will try acct and lastcomm next. Thanks
    – MountainX
    Aug 9, 2013 at 3:43
  • updated question
    – MountainX
    Aug 9, 2013 at 4:19
  • still looking for a solution...
    – MountainX
    Aug 10, 2013 at 18:33
  • Please post the output of lastcomm for a full session, not just the ssh-agent process. The point is to see in what order various programs are started. Aug 10, 2013 at 22:58

5 Answers 5


For the

$ eval `ssh-agent -s`

construct to work when put in a “startup script”, your session, and ultimately the terminal where you expect the environment, must be descendants (by fork and exec) of that script. The reason is that the output of ssh-agent -s, when evaluated, sets environment variables in the shell calling eval. Form there, they may be handed down, and they may be lost on the way as well.

So if ssh-agent is run by script A somewhere during login, but the terminal B in which you start you shell script is not a descendant of A, then you cannot see the environment in B.

If you happen to have ssh-agent started as systemd --user service, then you may have to use convention instead: Don't let ssh-agent specify the variables, but use common knowledge when starting the agent, and when starting the session. E.g., my ~/.config/systemd/user/ssh-agent.service looks like this:

Description=SSH agent

ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK


And in my ~/.profile I have the line

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Note that %t in the former corresponds to ${XDG_RUNTIME_DIR} in the latter.

Note: I'm not happy about this!

  • Can you please explain the problems of this approach (i.e., why are you not happy about this) and whether or not you've found a better approach in the meantime? Feb 17 at 6:30

You mentioned your user is sshing in, not logging in locally. So the use-ssh-agent in /etc/X11/Xsession.options is a red herring: it won't be executed on SSH sessions, only when logging into a X11 GUI desktop locally (or using some virtual X11 session like over VNC or RDP).

Instead, you should check if libpam-ssh is installed on either system. It can be configured to authenticate a user using SSH private key passphrases, but that is optional and you'll need to specifically place the key to ~/.ssh/login-keys.d/ for that functionality.

Its other feature, though, is to auto-start a SSH agent on any login session and automatically add SSH private keys to the agent if their passphrase is the same as the user's login password. I'm thinking this might be the cause of the different behavior between your systems.

  • A fresh install of Ubuntu 22.04 wasn't starting ssh-agent when I logged in over ssh. From past experience with ubuntu, I know it's configured to start ssh-agent. Turns out this new install didn't have libpam-ssh installed. Installing that package fixed it: now my login shells have an ssh-agent running and get the right $SSH_ env vars.
    – dgrogan
    Oct 21, 2022 at 21:24
  • @dgrogan's solution work for me as well (for ssh login on Ubuntu 23). No need to edit any dot file. Just do "sudo apt install libpam-ssh" and you are done.
    – 3r1d
    Jan 24 at 6:57

You mentioned that

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

works as desired. So you just need those to execute at the right time, in .bash_profile or .xsession. Add debug statements like (date; env|sort) >> /tmp/log to help you understand exactly when they run.


I found the answer here :


On ubuntu the ssh-add utility fails to load certificate files. It occurs when the agent is the one implemented by gnome-keyring. The fix is to stop using the ssh component of gnome-keyring. Since the initialization process actually starts up a true ssh-agent and then launches gnome-keyring-ssh.desktop which clobbers AUTH_SOCKET to take it over, we can revert back to the original ssh-agent by disabling gnome-keyring-ssh.desktop.

Disable gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Add the following line to the desktop file and save it, then reboot:

  • Only that your so-called "true" ssh-agent doesn't access the gnome keyring and therefore still requests the password after every reboot.
    – Bachsau
    Feb 25 at 9:53

SSH-Keygen for Multi-User Jupyterhub Python Environment:

Trying to setup SSH-Keygen in a multi-user Jupyter Python environment has proved a major frustration... This of course is obviously preferable to plain text http password for git.

I didn't realize that the SSH_AUTH_SOCK wasn't getting carried over to my ssh-add after running the eval ssh-agent cmd... @stefan gave a very nice description above which put this all in perspective! More helpful info on ssh-add man page here as well...

You need to run everything in a single bash cmd!

Below is an example following instructions from GitHub here on ssh key generation.

  • Please notice I use ! (bang) in the python cell so it runs a bash command in jupyter. More info here.
  • Also notice the && \ to wrap my bash command inside a jupyter python notebook cell so it's ONE command:
!ssh-keygen -t ed25519 -C "[email protected]" -f $HOME/.ssh/id_ed25519 -N "" <<< y && \
eval "$(ssh-agent -s)" && \
ssh-add $HOME/.ssh/id_ed25519

Confirm your SSH setup

Proceed by adding your SSH key to github. You should then be able to confirm your github authentication, this worked for me when running the following:

!ssh -o "StrictHostKeyChecking no" -T user@[email protected]
  • Please note the flag -o "StrictHostKeyChecking no" is NOT recommended given there could be a man-in-the-middle attack. I am unsure how to programattically accept this with value yes, alternatively you can probably get the known host and manually add to your known host file.
  • Just a note about your one-liner, it seems you are specifying ED25519 encryption but then name you key with RSA. Is there a reason?
    – skube
    Aug 3, 2022 at 10:40
  • No reason other than the fact that most guides online default to RSA and honestly I didn't catch notice. Really though you can name the public and private key whatever you want, probably best to be consistent with recommended extensions here docs.gitlab.com/ee/user/… (I edited my response to reflect this best practice) Aug 4, 2022 at 15:26

You must log in to answer this question.

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