Ssh-add is forgotten if new gnome-terminal is opened

ssh-agent

After a:

eval `ssh-agent -s`
ssh-add

I can log in to a "server" via ssh without pwd.

Question: But If I open a new gnome-terminal I have to do this again, why?

Using RHEL Desktop 6.6 with GNOME.

UPDATE #1: interesting, another RHEL Desktop doesn't runs ssh-agent, it only needs an "ssh-add" per boot. But issuing an "ssh-add" on the "bad desktop" only gives an error message: "Could not open a connection to your authentication agent."

UPDATE #2: SSH_AUTH_SOCK is missing after a fresh reboot, maybe that is the problem?:

[user@notebook ~]$ env | grep SSH
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
[user@notebook ~]$

Best Answer

ssh-add and ssh refer to a couple of environment variables to find the SSH agent to talk to: SSH_AGENT_PID and SSH_AUTH_SOCK. When you run

eval `ssh-agent -s`

ssh-agent outputs the values and your shell interprets them; they are set in the shell the command is run from, and that shell only. Thus when you start a new terminal, the new shell in that terminal doesn't have those variables set appropriately and ssh can't find the agent.

If you have both terminals running, you can run

env | grep SSH

in the terminal you started the agent from, and set the values given in the new terminal. Then ssh should find the agent in the second terminal.

A better solution though is to use the SSH agent integration in GNOME, as provided by gnome-keyring. I'm not sure how things are set up in RHEL Desktop, but you can try simply running ssh-add without starting the agent beforehand...

The GNOME keyring SSH documentation may be helpful; in particular, you may want to check whether the SSH Key Agent is enabled in your startup applications (in the GNOME properties).

Related Solutions

Bash – ssh-agent not getting set up (SSH_AUTH_SOCK, SSH_AGENT_PID env vars not set)

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.

SSH – Add All Private Keys in .ssh Directory with ssh-add

Slightly convoluted, but:

for possiblekey in ${HOME}/.ssh/id_*; do
    if grep -q PRIVATE "$possiblekey"; then
        ssh-add "$possiblekey"
    fi
done

You can also add all of your keys to your ~/.ssh/config each in their own IdentityFile directive outside of a Host directive:

# Global SSH configurations here will be applied to all hosts
IdentityFile ~/.ssh/id_dsa
IdentityFile ~/.ssh/id_project1
IdentityFile ~/.ssh/id_someotherkey

Host somespecifichost.example.com
    IdentityFile ~/.ssh/id_specifichostonlykey

The latter, honestly-better, method has the added perk of not suddenly picking up a new key that you've added without you explicitly adding it to the "keyring" as it were.

Best Answer

Related Solutions

Bash – ssh-agent not getting set up (SSH_AUTH_SOCK, SSH_AGENT_PID env vars not set)

SSH – Add All Private Keys in .ssh Directory with ssh-add

Related Question