Who is starting my ssh-agent, and why won't it properly terminate?












8















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 exiting: 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 using useradd -m dummy, and logging into it doesn't start any ssh-agent (I feel like this could mean something). The diff /home/pi/.bashrc /home/dummy/.bashrc shows basically nothing (just a comment I made), same for diff /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 using grep 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:




  1. Where and how is this ssh-agent spawned, who issues the command?

  2. 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?










share|improve this question

























  • I do wonder what you have in your ~/.bashrc then.

    – ilkkachu
    Jan 28 '18 at 10:27











  • @ilkkachu well, here you go...

    – Marco Bonelli
    Jan 28 '18 at 13:16
















8















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 exiting: 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 using useradd -m dummy, and logging into it doesn't start any ssh-agent (I feel like this could mean something). The diff /home/pi/.bashrc /home/dummy/.bashrc shows basically nothing (just a comment I made), same for diff /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 using grep 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:




  1. Where and how is this ssh-agent spawned, who issues the command?

  2. 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?










share|improve this question

























  • I do wonder what you have in your ~/.bashrc then.

    – ilkkachu
    Jan 28 '18 at 10:27











  • @ilkkachu well, here you go...

    – Marco Bonelli
    Jan 28 '18 at 13:16














8












8








8








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 exiting: 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 using useradd -m dummy, and logging into it doesn't start any ssh-agent (I feel like this could mean something). The diff /home/pi/.bashrc /home/dummy/.bashrc shows basically nothing (just a comment I made), same for diff /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 using grep 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:




  1. Where and how is this ssh-agent spawned, who issues the command?

  2. 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?










share|improve this question
















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 exiting: 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 using useradd -m dummy, and logging into it doesn't start any ssh-agent (I feel like this could mean something). The diff /home/pi/.bashrc /home/dummy/.bashrc shows basically nothing (just a comment I made), same for diff /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 using grep 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:




  1. Where and how is this ssh-agent spawned, who issues the command?

  2. 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?







ssh login raspbian openssh ssh-agent






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 5 at 22:13







Marco Bonelli

















asked Jan 27 '18 at 23:05









Marco BonelliMarco Bonelli

26213




26213













  • I do wonder what you have in your ~/.bashrc then.

    – ilkkachu
    Jan 28 '18 at 10:27











  • @ilkkachu well, here you go...

    – Marco Bonelli
    Jan 28 '18 at 13:16



















  • I do wonder what you have in your ~/.bashrc then.

    – ilkkachu
    Jan 28 '18 at 10:27











  • @ilkkachu well, here you go...

    – Marco Bonelli
    Jan 28 '18 at 13:16

















I do wonder what you have in your ~/.bashrc then.

– ilkkachu
Jan 28 '18 at 10:27





I do wonder what you have in your ~/.bashrc then.

– ilkkachu
Jan 28 '18 at 10:27













@ilkkachu well, here you go...

– Marco Bonelli
Jan 28 '18 at 13:16





@ilkkachu well, here you go...

– Marco Bonelli
Jan 28 '18 at 13:16










1 Answer
1






active

oldest

votes


















1














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 the ssh-agent too. Its shut-down is handled differently, so there will be only the SSH_AUTH_SOCK environment variable, not the SSH_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 only SSH_AUTH_SOCK without the SSH_AGENT_PID... because the agent socket goes to sshd which tunnels it back to your local workstation's SSH agent.







share|improve this answer



















  • 1





    Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

    – Marco Bonelli
    Jan 28 '18 at 2:25













Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420124%2fwho-is-starting-my-ssh-agent-and-why-wont-it-properly-terminate%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














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 the ssh-agent too. Its shut-down is handled differently, so there will be only the SSH_AUTH_SOCK environment variable, not the SSH_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 only SSH_AUTH_SOCK without the SSH_AGENT_PID... because the agent socket goes to sshd which tunnels it back to your local workstation's SSH agent.







share|improve this answer



















  • 1





    Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

    – Marco Bonelli
    Jan 28 '18 at 2:25


















1














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 the ssh-agent too. Its shut-down is handled differently, so there will be only the SSH_AUTH_SOCK environment variable, not the SSH_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 only SSH_AUTH_SOCK without the SSH_AGENT_PID... because the agent socket goes to sshd which tunnels it back to your local workstation's SSH agent.







share|improve this answer



















  • 1





    Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

    – Marco Bonelli
    Jan 28 '18 at 2:25
















1












1








1







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 the ssh-agent too. Its shut-down is handled differently, so there will be only the SSH_AUTH_SOCK environment variable, not the SSH_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 only SSH_AUTH_SOCK without the SSH_AGENT_PID... because the agent socket goes to sshd which tunnels it back to your local workstation's SSH agent.







share|improve this 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 the ssh-agent too. Its shut-down is handled differently, so there will be only the SSH_AUTH_SOCK environment variable, not the SSH_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 only SSH_AUTH_SOCK without the SSH_AGENT_PID... because the agent socket goes to sshd which tunnels it back to your local workstation's SSH agent.








share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 28 '18 at 1:58









telcoMtelcoM

16.1k12144




16.1k12144








  • 1





    Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

    – Marco Bonelli
    Jan 28 '18 at 2:25
















  • 1





    Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

    – Marco Bonelli
    Jan 28 '18 at 2:25










1




1





Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

– Marco Bonelli
Jan 28 '18 at 2:25







Thank you for the suggestions, but unfortunately none of those options apply to me. I don't have libpam-ssh; both SSH_AGENT_PID and SSH_AUTH_SOCK are unset (the socket is of course present anyway); I don't use gpg-agent and don't have agent forwarding enabled on PuTTY. I'm really lost :

– Marco Bonelli
Jan 28 '18 at 2:25




















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420124%2fwho-is-starting-my-ssh-agent-and-why-wont-it-properly-terminate%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre