Could not open a connection to your authentication agent (REVIEW)

Question

First of all, I am aware that this question has been posted several times in stack overflow here, here, here, as well as in some other places.

However, I decided to open a new thread (and taking the risk of being downvoted) because I don't think there is an actual issue with my machine, but with PUTTY.

Environment description

In a nutshell, I have a windows machine running a virtual machine (VMWare).

1. Host machine: Windows 7 (64 bit)
2. Guest machine: CentOS 6 with graphic windows environment.
3. Network connection perfectly setup, so no problems with firewall. Both machines are pingeable from each other, and I can surf the internet from both
4. Selinux disabled on guest machine
5. Putty is properly configured (or so I think). The reasons to back up the statement is that I can SSH the guest machine from the host machine with the encrypted SSH keys that I created for that matter. However, I think there is still some configuration missing. Keep reading.
6. I have configured GITOLITE on the guest machine, and it is up and running.
7. Although not relevant for this issue, I have a Samba share configured on the guest machine, were I have all my repos. The share is accessible from the host machine, and I can edit the files with no problem whatsoever.
8. VM Player 7
9. Guest machine recently restarted and no additional commands have been issued.
10. PUTTY installed in the host machine

Case scenario #1 (it works)

This case scenario describes the behaviour I expect to achieve. Basically, this procedure is being done within the VM itself. That means, by operating the machine through the VM Player.

1. Open a terminal as root
2. service sshd status yields openssh-daemon (pid 1557) is running...
3. ssh-add -l yields 2048 1b:31 [...] b8:de Git Admin (RSA), 2048 d2:58 [...] f6:2b pando (RSA) and (2048) be:9b [...] dc:e9 web (RSA). These are the three users I have configured in my virtual machine. The SSH keys have been automatically loaded and added to the list of identities of the SSH service.
4. Log out as root from the CLI. I am now an standard user (the pando user).
5. Edit one file in one of the repos
6. git commit -a -m "My message" is successful because the Git Admin key is in the identity list of the SSH agent
7. git push origin master is also successful, for the same reasons

Case scenario #2 (it does not work)

This case scenario describes the same procedure, but from the Putty terminal. I added to the Pageant the same SSH keys as described in Case Scenario #1, point 3. It looks like everything is Ok with Putty, because I can successfully SSH my virtual machine

1. Open the Putty Terminal. I am logged in as user pando (which is one of the identities mentioned in Case Scenario 1).
2. su
3. service sshd status yields openssh-daemon (pid 1557) is running... (notice that it is the same result as we got in point #2 of the first case scenario)
4. ssh-add -l yields Could not open a connection to your authentication agent
5. Because the previous step failed, I have all the issues described in the hyperlinked threads at the beginning of this post.

Now, I am familiar with that procedure of eval $(ssh-agent) and then to manually add the SSH keys on my SSH folder. In fact, I do that every time I SSH the virtual machine. But I actually prefer not to do it.

I am also familiar with adding some script to the .bashsrc file, but the last time I did it, I got a colateral effect with Puppet.

So the basic question is: What's the difference betwen both case scenarios, even though I am using the same SSH keys? Is it that Pageant is not forwarding the keys? If so, why am I able to SSH my machine? Why should I change the .bashrc file of my pando user in the second case scenario, when I can achieve exactly the same thing without it in the first case scenario? I guess I am missing a fundamental piece of information here

Hope that makes sense.

Regards.

Answer 1

openssh-daemon and authentication-daemon are not the same thing. You are interested in the authentication one aka ssh-agent, which is your personal key-store. The openssh-deamon aka sshd is server that is running system-wide and which is accepting connections to your computer.

Desktop environments usually start authentication agents (ssh-agent, seahorse, gnome-keyring) by default so the ssh-add works for you. But the connection is stored in environment variables, which are dropped in transition from your user to superuser (su).

You can allow connection persistence using -m switch to su. This will preserve environment variables and so your connection to authentication agent.

---

What's the difference between both case scenarios, even though I am using the same SSH keys?

There should be no difference, except the su part dropping environment variables and not executing .bashrc and similar scripts when changing user (you can force su to behave the same way as a login shell using su -l, but it is not the problem). The problem is that the connection to authentication agent is preserved as environment variable and UNIX domain socket, which gets lost during su. You can use su -m it should work for you.

Is it that Pageant is not forwarding the keys?

Forwarding needs to be allowed in PuTTY: