SSH (no key forwarding) 2 June 2010

Zdarzyło mi się parę razy w Ubuntu, że klucz SSH nie był przekazywany dalej. Do pewnego momentu działało, ale po otwarciu na raz kilkudziesięciu sesji SSH wszystko szlag trafiał. Przyczyna leży w agencie kluczy, którym dla Gnome może byćssh-agent. Ginie bez powodu pozostając w systemie jako zombiak.

Możesz próbować “zabić” proces zombie, ale w 99,9% polegniesz :) No chyba, że zrestartujesz swój PC, albo ubijesz proces-rodzic. Tak czy siak, możesz wysłać do zombiaka seryjkę z karabinu maszynowego napakowanego różnymi systemowymi sygnałami, ognia!

for signal in {0..20}; do
    kill -${signal} `ps awfx|grep -v grep|grep Z|awk '{print $1}'`
done

lub zabijać proces-rodzic:

# ps -awfx|grep -v grep
  960 ?        Ss     0:00 gdm-binary
 1160 ?        S      0:00  \_ /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
 1175 tty7     Ss+   17:02      \_ /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-6RpoH3/database -nolisten tcp vt7
 2051 ?        S      0:00      \_ /usr/lib/gdm/gdm-session-worker
 2714 ?        Ssl    0:00          \_ gnome-session
 2834 ?        Zs     0:00              \_ [ssh-agent] <defunct>
 3000 ?        S      1:23              \_ metacity --sm-client-id ***
 3002 ?        Sl     1:08              \_ gnome-panel --sm-config-prefix /gnome-panel-kINX8m/ --sm-client-id *** --screen 0
 3006 ?        S      0:16              \_ nautilus
 3022 ?        S      0:00              \_ /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
 3032 ?        S      0:00              \_ /usr/lib/gnome-disk-utility/gdu-notification-daemon
 3034 ?        S      0:00              \_ python /usr/share/system-config-printer/applet.py
 3037 ?        S      0:00              \_ gnome-volume-control-applet

Tutaj rodzicem dla ssh-agent’a jest proces o PID-zie 2714:

Teraz masz do wyboru:

  1. zabić rodzica, co chyba jest głupim pomysłem, bo zabijesz całą sesję Gnome:)
  2. znaleźć przyczynę, dlaczego ssh-agent nie przekazuje tych cholernych kluczy!

Idziemy za opcją 2. Zanim zaczniemy, dobrze jest sprawdzić, czy twój publiczny klucz SSH jest respektowany przez zdalny serer:

# cd ~/.ssh
# ls -al
# ln -s mykey id_dsa
# ssh root@server
# albo, opcja inna to po prostu skorzystać z opcji -i:
# ssh -i mykey root@server

Załóżę się, że zadziała i możesz zostać przy tym, ale zapewniam, że będziesz tego żałować, jeśli potrzebujesz korzystać z kilkunastu sesji na raz :) Dobra, to teraz zobaczymy, którego keyringa używa ssh-agent:

# strace ssh-add
[...] at the very end you shoudll notice:
connect(3, {sa_family=AF_FILE, path="/tmp/keyring-4ZHEOn/socket.ssh"}, 110) = -1 ENOENT (No such file or directory)

# ls -al /tmp/keyring-4ZHEOn/socket.ssh
ls: /tmp/keyring-4ZHEOn/socket.ssh: No such file or directory

Idź do /tmp i wystartuj ssh-agent, zobacz ponownie jaka nazwę teraz otrzymał keyring i utwórz link symboliczny do nowego z nazwą starego (zagmatwane? chyba nie aż tak bardzi):

# gnome-keyring-daemon -c ssh
# cd /tmp
# ls -al |grep keyring
drwx------  2 krzysiek dba     4096 2010-02-12 13:55 keyring-oKwdoF
# ln -s keyring-oKwdoF keyring-4ZHEOn

Gotowe :) ssh-agent znowu działa. Pamiętaj, by otworzyć sobie nowe okienko z sesją terminala, by wprowadzone zmiany zadziałały. No ale te pieprzone zombiaki zostaną dopóki nie zrestartujesz komputera :/

Tagi: , , , , , , ,

«
»

Zostaw odpowiedź