Qui démarre mon agent ssh et pourquoi ne se termine-t-il pas correctement?

C'est un problème que j'ai depuis longtemps, mais chaque fois que j'essaie de comprendre quelque chose, je me perds, alors j'ai pensé que je ferais mieux de demander ici où peut-être quelqu'un de plus expérimenté pourrait m'aider.

Contexte

Mon Raspberry Pi exécute Raspbian Jessie, et j'utilise souvent SSH pour s'y connecter et exécuter des commandes à distance. Lors de mes premières sessions SSH, j'ai remarqué qu'un ssh-agentprocessus était généré sur le RPi chaque fois que je me connectais , mais jamais tué lors de la exitconnexion: la connexion et la déconnexion à plusieurs reprises provoquaient la génération d' un tas de ssh-agentprocessus juste pour être laissés accrochés là sans rien faire. En tripotant et en lisant des pages de manuel et des réponses ici et là, j'ai récemment compris le but de ssh-agent, et j'ai également appris qu'il devrait normalement être tué lors de la déconnexion, alors j'ai commencé à me demander pourquoi ce n'était pas le cas. De plus, j'ai remarqué que l'émission source ~/.bashrcprovoque la génération d' une autre instance de ssh-agent. J'ai lu sur la page de manuel relativeque la variable d'environnement SSH_AGENT_PIDdoit être défini parce que le ssh-agentprogramme devrait être lancé dans un evalpour exécuter sa sortie et définir ces variables, qui sont ensuite utilisées par d' autres commandes liées à SSH, y compris ssh-agent -k(pour tuer l'agent par rapport à la session en cours), je couru echo $SSH_AGENT_PIDet echo $SSH_AUTH_SOCK, mais ils étaient tous les deux vides. Je me suis soudain rendu compte: le processus n'est probablement pas tué à la déconnexion, car il ssh-agent -kessaie de lire son PID à partir de la variable d'environnement qui n'est pas définie.

Le problème

Puisque ssh-agentn'est pas tué à la déconnexion, et cela se produit à coup sûr parce que les variables d'environnement nécessaires ne sont pas définies, cela ne peut signifier qu'une chose: celui qui appelle ssh-agentà la connexion ne le fait probablement pas correctement (ce qui serait le cas eval "$(ssh-agent -s)") . Alors j'ai pensé: eh bien, quel est le problème? Je vais simplement trouver le fichier de configuration, le service ou le script de connexion exécuté pour démarrer l'agent et le corriger manuellement! Où diable cela pourrait-il être?

Ce que j'ai essayé

Depuis que j'ai remarqué qu'un an ssh-agentapparaît chaque fois que j'appelle source ~/.bashrc, c'est le premier fichier que j'ai inspecté, mais rien là-bas ne fait référence à distance à quoi que ce soit lié à SSH. J'ai continué à chercher en utilisant vila chaîne sshdans tous les fichiers suivants, mais je n'ai rien trouvé :

~/.bashrc
~/.profile
/etc/bash.bashrc
/etc/profile
/etc/profile.d/ (every file in this folder)
/etc/environment

Y a-t-il d'autres fichiers qui pourraient être impliqués source ~/.bashrc? Je ne sais pas vraiment.

Ensuite, j'ai recherché les systemdservices pertinents , mais je n'ai trouvé que ssh.servicece qui est WantedBy=multi-user.target, et n'est donc pas exécuté lors de la connexion (et bien, c'est évident car il s'agit du démon du serveur SSH).

J'ai également essayé de déplacer chaque fichier de mon /home/pidossier vers un dossier temporaire et de me déconnecter puis de me reconnecter, mais j'ai tout dessh-agent même généré.

Finalement, j'ai également tiré le dernier coup que j'ai eu dans la chambre: j'ai couru en find / -name 'ssh-agent'tant que root, qui ne faisait qu'imprimer /usr/bin/ssh-agent, un exécutable, j'ai donc créé un faux exécutable qui n'a essentiellement consigné que la commande parent :

#! /bin/bash
ps -o args= $PPID        > /home/pi/LOG
cat /proc/$PPID/cmdline >> /home/pi/LOG

J'ai renommé le réel /usr/bin/ssh-agentet l' ai remplacé par le faux en définissant les bonnes autorisations / utilisateur / groupe, j'ai couru à source ~/.bashrcnouveau, puis j'ai imprimé le LOGfichier:

-bash
-bash

Pas un seul indice sur ce qui se passe.

Quelques détails supplémentaires

J'ajoute quelques détails, je ne sais pas s'ils pourraient être utiles ou non, mais vous savez ... mieux vaut prévenir que guérir.

• Voici mon .bashrc.

• J'ai créé un nouvel utilisateur nommé dummyusing useradd -m dummy, et la connexion ne démarre passsh-agent (je pense que cela pourrait signifier quelque chose). Le diff /home/pi/.bashrc /home/dummy/.bashrcspectacle ne montre pratiquement rien (juste un commentaire que j'ai fait), pareil pour diff /home/pi/.profile /home/dummy/.profile.

• Le socket d'agent est créé sans problème même s'il SSH_AUTH_SOCKn'est pas défini:

  pi:~$ ls -lAh /tmp/ssh-vQRTAyj7DJry/
  total 0
  srw------- 1 pi pi 0 Jan 28 03:12 agent.1328
  

  Je ne sais pas pourquoi, mais le numéro sur le nom de fichier du socket est toujours celui immédiatement avant le PID du ssh-agentprocessus.

• Extrait de 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
  

• Packages installés correspondant 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]
  

• La recherche ssh-agent -srécursive utilisant grepin /etcet /libne donne aucun résultat.

• Je n'ai aucun environnement de bureau installé, mais j'ai un /etc/X11dossier contenant des fichiers de configuration. J'ai essayé de renommer le dossier en quelque chose d'autre et de redémarrer au cas où, mais le processus est toujours généré, donc apparemment, cela n'a pas grand-chose à voir avec cela.

Conclusion

Maintenant, pour le rendre aussi simple que possible, je n'ai que deux questions:

1. Où et comment cela est-il ssh-agentengendré, qui émet la commande?
2. Pourquoi n'est-il pas appelé de la bonne manière, sans définir les variables d'environnement nécessaires, et donc laisser le processus se bloquer indéfiniment?

Je connais quelques raisons possibles:

• si vous utilisez libpam-ssh, il peut automatiquement démarrer un agent SSH pour vous dans le cadre du démarrage d'une session, et même charger automatiquement vos clés si elles n'ont pas de phrase secrète ou si leur phrase secrète est la même que votre mot de passe de connexion.

• si vous utilisez gpg-agent, il peut éventuellement effectuer la tâche du ssh-agent. Son arrêt est géré différemment, il n'y aura donc que la SSH_AUTH_SOCKvariable d'environnement, pas la variableSSH_AGENT_PID

• si vous avez un agent SSH (par exemple PuTTY's Pageant) en cours d'exécution sur votre poste de travail et établissez une connexion SSH avec le transfert d'agent activé (et la télécommande le sshdpermet), sur l'hôte distant, vous ne verrez à nouveau que SSH_AUTH_SOCKsans le SSH_AGENT_PID... car le socket de l'agent va vers sshdquels tunnels il retourne à l'agent SSH de votre poste de travail local.