This is a problem I've been having for a long time, but every time I try to figure something out I get lost, so I figured I'd better ask here where maybe someone more experienced could help me.
Background
My Raspberry Pi is running Raspbian Jessie, and I use SSH often to login into it and execute commands remotely. During my first SSH sessions I noticed that an ssh-agent
process was spawned on the RPi every time I logged in, but never killed when exit
ing: logging in and out several times caused a bunch of ssh-agent
processes to be spawned just to be left hanging there doing nothing. Fiddling around and reading man pages and answers here and there I recently understood the purpose of ssh-agent
, and I also learned that it should normally get killed when logging out, so I began to ask myself why it wasn't. Furthermore, I noticed that issuing source ~/.bashrc
causes another instance of ssh-agent
to be spawned. I read on the relative man page that the environment variable SSH_AGENT_PID
should be defined because the ssh-agent
program should be started within an eval
to execute its output and define such variables, which are then used by other SSH-related commands, including ssh-agent -k
(to kill the agent relative to the current session), so I ran echo $SSH_AGENT_PID
and echo $SSH_AUTH_SOCK
, but they were both empty. I suddenly realized: probably the process doesn't get killed on logout because ssh-agent -k
tries to read its PID from the environment variable which is not set.
The problem
Since ssh-agent
is not being killed on logout, and this for sure happens because the needed environment variables aren't set, it can only mean one thing: whoever calls ssh-agent
on login probably doesn't do it in the proper way (which would be eval "$(ssh-agent -s)"
). So I thought: well, what's the problem? I'll just find whichever configuration file, service, or login script gets executed to start the agent and manually fix it! Where on earth could it be?
What I've tried
Since I noticed that an ssh-agent
is spawned every time I call source ~/.bashrc
, this was the first file I inspected, but nothing there even remotely referenced anything related to SSH. I kept searching using vi
for the string ssh
inside all the following files, but found nothing:
~/.bashrc
~/.profile
/etc/bash.bashrc
/etc/profile
/etc/profile.d/ (every file in this folder)
/etc/environment
Is there some more file that could be involved in source ~/.bashrc
? I don't really know.
Then I searched for relevant systemd
services, but only found ssh.service
, which is WantedBy=multi-user.target
, and therefore is not run on login (and well, that's obvious since this is the SSH server daemon).
I also tried moving every single file in my /home/pi
folder to a temporary folder and logging out and back in again, but ssh-agent
still spawned.
Eventually, I also fired the last shot I had in the chamber: I ran find / -name 'ssh-agent'
as root, which only printed /usr/bin/ssh-agent
, an executable, so I created a fake executable which basically only logged the parent command:
#! /bin/bash
ps -o args= $PPID > /home/pi/LOG
cat /proc/$PPID/cmdline >> /home/pi/LOG
I renamed the real /usr/bin/ssh-agent
and replaced it with the fake one setting the right permissions/user/group, ran source ~/.bashrc
again, then printed the LOG
file:
-bash
-bash
Not a single clue on what is going on.
Some more details
I'm adding some more details, I don't know if they could be helpful or not, but you know… better safe than sorry.
-
Here's my
.bashrc
. -
I created a new user named
dummy
usinguseradd -m dummy
, and logging into it doesn't start anyssh-agent
(I feel like this could mean something). Thediff /home/pi/.bashrc /home/dummy/.bashrc
shows basically nothing (just a comment I made), same fordiff /home/pi/.profile /home/dummy/.profile
. -
The agent socket is created without problem even though
SSH_AUTH_SOCK
is not set:pi:~$ ls -lAh /tmp/ssh-vQRTAyj7DJry/ total 0 srw------- 1 pi pi 0 Jan 28 03:12 agent.1328
Not sure why, but the number on the socket filename is always the one immediately before the PID of the
ssh-agent
process. -
Snippet from
htop
:PID USER PRI NI VIRT RES SHR S Command 1 root 20 0 5472 3900 2728 S /sbin/init 1329 pi 20 0 3696 224 16 S └─ ssh-agent -s
-
Installed packages matching
ssh
:pi:~$ apt list --installed | grep ssh libpam-chksshpwd/oldstable,now 1.1.8-3.1+deb8u2+rpi3 armhf [installed] libssh-gcrypt-4/oldstable,now 0.6.3-4+deb8u2 armhf [installed,automatic] libssh2-1/oldstable,now 1.4.3-4.1+deb8u1 armhf [installed,automatic] openssh-client/oldstable,now 1:6.7p1-5+deb8u4 armhf [installed,automatic] openssh-server/oldstable,now 1:6.7p1-5+deb8u4 armhf [installed,automatic] openssh-sftp-server/oldstable,now 1:6.7p1-5+deb8u4 armhf [installed,automatic] ssh/oldstable,now 1:6.7p1-5+deb8u4 all [installed] sshpass/oldstable,now 1.05-1 armhf [installed]
-
Searching for
ssh-agent -s
recursively usinggrep
in/etc
and/lib
yields no results. -
I have no desktop environment installed, but I have a
/etc/X11
folder with some configuration files in it. I tried renaming the folder to something else and rebooting just in case, but the process still gets spawned, so apparently that doesn't have much to do with this.
Conclusion
Now, to make it as simple as possible, I've only got two questions:
- Where and how is this
ssh-agent
spawned, who issues the command? - Why doesn't it get called in the proper way, without setting the needed environment variables, and therefore leaving the process to hang there indefinitely?
Best Answer
I know a couple possible reasons:
if you're using
libpam-ssh
, it can automatically start a SSH agent for you as part of a session start-up, and even automatically load your keys if they either have no passphrase or their passphrase is the same as your login password.if you are using
gpg-agent
, it can optionally perform the task of thessh-agent
too. Its shut-down is handled differently, so there will be only theSSH_AUTH_SOCK
environment variable, not theSSH_AGENT_PID
if you have SSH-agent (e.g. PuTTY's Pageant) running on your workstation and make a SSH connection with agent forwarding enabled (and the remote
sshd
allows it), on the remote host you will again see onlySSH_AUTH_SOCK
without theSSH_AGENT_PID
... because the agent socket goes tosshd
which tunnels it back to your local workstation's SSH agent.