Kto uruchamia mojego agenta ssh i dlaczego nie zostanie poprawnie zakończony?

Jest to problem, który mam od dłuższego czasu, ale za każdym razem, gdy próbuję coś wymyślić, gubię się, więc pomyślałem, że lepiej zapytam tutaj, gdzie może ktoś bardziej doświadczony może mi pomóc.

tło

W moim Raspberry Pi działa Raspbian Jessie i często używam SSH do logowania się i wykonywania poleceń zdalnie. Podczas moich pierwszych sesji SSH zauważyłem, że ssh-agentproces pojawiał się na RPi za każdym razem, gdy się logowałem, ale nigdy nie został zabity podczas exiting: zalogowanie się i wylogowanie spowodowało, że wiele ssh-agentprocesów zostało odrodzonych, po prostu zostawiając się wisi bezczynnie. Bawiąc się i czytając strony podręcznika użytkownika i odpowiedzi tu i tam, zrozumiałem niedawno cel ssh-agent, a także nauczyłem się, że normalnie powinien zostać zabity podczas wylogowywania, więc zacząłem zadawać sobie pytanie, dlaczego tak nie było. Ponadto zauważyłem, że wydanie source ~/.bashrcpowoduje pojawienie ssh-agentsię kolejnej instancji . Czytam na względnej stronie manże zmienna środowiskowa SSH_AGENT_PIDpowinna zostać zdefiniowana, ponieważ ssh-agentprogram powinien zostać uruchomiony w evalcelu wykonania danych wyjściowych i zdefiniowania takich zmiennych, które są następnie używane przez inne polecenia związane z SSH, w tym ssh-agent -k(do zabicia agenta względem bieżącej sesji), więc I pobiegł echo $SSH_AGENT_PIDi echo $SSH_AUTH_SOCK, ale oba były puste. Nagle zdałem sobie sprawę: prawdopodobnie proces nie ginie podczas wylogowywania, ponieważ ssh-agent -kpróbuje odczytać swój PID ze zmiennej środowiskowej, która nie jest ustawiona.

Problem

Ponieważ ssh-agentnie jest zabijany podczas wylogowywania, a na pewno dzieje się tak, ponieważ potrzebne zmienne środowiskowe nie są ustawione, może to oznaczać tylko jedno: ktokolwiek wywołuje ssh-agentlogin prawdopodobnie nie robi tego we właściwy sposób (co byłoby eval "$(ssh-agent -s)") . Pomyślałem więc: w czym problem? Po prostu znajdę plik konfiguracyjny, usługę lub skrypt logowania, który zostanie uruchomiony, aby uruchomić agenta i ręcznie go naprawić! Gdzie to może być?

Co próbowałem

Ponieważ zauważyłem, że za ssh-agentkażdym razem, gdy dzwonię source ~/.bashrc, spawnuje się , był to pierwszy sprawdzony przeze mnie plik, ale nic tam nawet nie nawiązało do niczego związanego z SSH. Ciągle szukałem za pomocą viciągu sshwewnątrz wszystkich następujących plików, ale nic nie znalazłem :

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

Czy jest jeszcze jakiś plik, w który można zaangażować source ~/.bashrc? Naprawdę nie wiem.

Potem szukałem odpowiednich systemdusług , ale tylko znalazłem ssh.service, co jest WantedBy=multi-user.targeti dlatego nie jest uruchamiane przy logowaniu (i cóż, to oczywiste, ponieważ jest to demon serwera SSH).

Próbowałem/home/pi także przenieść każdy pojedynczy plik w moim folderze do folderu tymczasowego i wylogować się i ponownie zalogować, ale ssh-agentnadal się odradzałem.

W końcu wystrzeliłem także ostatni strzał, który miałem w komorze: uruchomiłem się find / -name 'ssh-agent'jako root, który tylko wydrukował /usr/bin/ssh-agent, plik wykonywalny, więc stworzyłem fałszywy plik wykonywalny, który w zasadzie rejestrował tylko polecenie nadrzędne :

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

Zmieniłem nazwę rzeczywistą /usr/bin/ssh-agenti zastąpiłem ją fałszywą, ustawiając odpowiednie uprawnienia / użytkownik / grupa, uruchomiłem source ~/.bashrcponownie, a następnie wydrukowałem LOGplik:

-bash
-bash

Ani jednej wskazówki, co się dzieje.

Więcej szczegółów

Dodaję więcej szczegółów, nie wiem, czy mogłyby być pomocne, czy nie, ale wiesz ... lepiej być bezpiecznym niż żałować.

• Oto mój .bashrc.

• Utworzyłem nowego użytkownika o nazwie dummyusing useradd -m dummy, a zalogowanie się do niego nie uruchamia żadnegossh-agent (wydaje mi się, że to może coś znaczyć). Programy w diff /home/pi/.bashrc /home/dummy/.bashrczasadzie nic (tylko komentarz, który napisałem), to samo dla diff /home/pi/.profile /home/dummy/.profile.

• Gniazdo agenta jest tworzone bez problemu, mimo że SSH_AUTH_SOCKnie jest ustawione:

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

  Nie jestem pewien, dlaczego, ale numer w nazwie pliku gniazda jest zawsze numerem bezpośrednio przed PID ssh-agentprocesu.

• Fragment z 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
  

• Zainstalowane pakiety pasujące 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]
  

• Szukając ssh-agent -srekursywnie stosując grepw /etca /libplony bez rezultatu.

• Nie mam zainstalowanego środowiska pulpitu, ale mam /etc/X11folder z niektórymi plikami konfiguracyjnymi. Próbowałem zmienić nazwę folderu na coś innego i zrestartować komputer na wszelki wypadek, ale proces wciąż się pojawia , więc najwyraźniej nie ma to wiele wspólnego z tym.

Wniosek

Teraz, aby maksymalnie uprościć, mam tylko dwa pytania:

1. Gdzie i jak się to pojawia ssh-agent, kto wydaje polecenie?
2. Dlaczego nie jest wywoływany w odpowiedni sposób, bez ustawiania potrzebnych zmiennych środowiskowych, a zatem pozostawiając proces zawieszony tam na czas nieokreślony?

Znam kilka możliwych powodów:

• jeśli używasz libpam-ssh, może automatycznie uruchomić agenta SSH w ramach uruchamiania sesji, a nawet automatycznie załadować klucze, jeśli nie mają hasła lub hasło jest takie samo jak hasło logowania.

• jeśli używasz gpg-agent, może opcjonalnie wykonać to ssh-agentsamo. Jego zamknięcie jest obsługiwane inaczej, więc będzie tylko SSH_AUTH_SOCKzmienna środowiskowa, a nieSSH_AGENT_PID

• jeśli masz agenta SSH (np. Pageant PuTTY) działającego na stacji roboczej i nawiązujesz połączenie SSH z włączonym przekazywaniem agenta (i zdalne sshdna to pozwala), na hoście zdalnym znów zobaczysz tylko SSH_AUTH_SOCKbez SSH_AGENT_PID... ponieważ gniazdo agenta idzie do sshdktórego tunelu wraca do agenta SSH lokalnej stacji roboczej.