Agent SSH nie konfiguruje się (SSH_AUTH_SOCK, SSH_AGENT_PID env vars nie ustawiono)

Założyłem nowe konto użytkownika dla znajomego na Kubuntu 12.04. Kiedy używa ssh, dostaje ten błąd:

Nie można otworzyć połączenia z agentem uwierzytelniającym

Biegniemy ssh w niektórych skryptach bash.

Po przeanalizowaniu różnych rzeczy, które mogą prowadzić do tego błędu, natknąłem się na to rozwiązanie:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Potem może uruchomić ssh polecenia (i skrypty bash) zgodnie z oczekiwaniami.

Przed uruchomieniem tych dwóch poleceń zmienne env nie są ustawiane w terminalu:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Po uruchomieniu poleceń zmienne env są ustawiane zgodnie z oczekiwaniami. Nie pozostają jednak ustawione (np. W innej powłoce lub po ponownym uruchomieniu).

Chcę wiedzieć, jak skonfigurować komputer, aby nie musiał uruchamiać tych dwóch poleceń, aby ustawić zmienne env. Nie muszę (nigdy) uruchamiać ich na moim komputerze. Jak dotąd nie widzę, co różni nasze maszyny.

Widzę te informacje na stronie podręcznika, ale nie mówi mi to, w jaki sposób Ubuntu normalnie konfiguruje agenta automatycznie lub co dzieje się na komputerze mojego przyjaciela, aby to nie działało.

Istnieją dwa główne sposoby skonfigurowania agenta: Pierwszy polega na tym, że agent uruchamia nową podkomendę, do której eksportowane są niektóre zmienne środowiskowe, np. Ssh-agent xterm &. Po drugie, agent drukuje potrzebne polecenia powłoki (można wygenerować składnię sh (1) lub csh (1)), które można wywołać w powłoce wywołującej, np. Eval ssh-agent -sdla powłok typu Bourne'a, takich jak sh (1) lub ksh (1) i eval ssh-agent -cdla csh (1) i instrumentów pochodnych.

Po zainstalowaniu accti ponownym uruchomieniu jest to wynik lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Ze strony podręcznika:

F - polecenie wykonywane po rozwidleniu, ale bez następnego exec

Nie jestem pewien, czy to jest znaczące.

Wspomniałeś, że użytkownik sshsię loguje, a nie loguje się lokalnie. Więc use-ssh-agentw/etc/X11/Xsession.options jest czerwony śledź: to nie będzie wykonywana na sesji SSH, tylko podczas logowania do pulpitu X11 GUI lokalnie (lub za pomocą jakiś wirtualny sesji X11 jak przez VNC lub PROW).

Zamiast tego powinieneś sprawdzić, czy libpam-sshjest zainstalowany w dowolnym systemie. Można go skonfigurować tak, aby uwierzytelniał użytkownika za pomocą haseł klucza prywatnego SSH, ale jest to opcjonalne i musisz specjalnie umieścić klucz w~/.ssh/login-keys.d/ dla tej funkcji.

Jednak jego drugą funkcją jest automatyczne uruchamianie agenta SSH podczas dowolnej sesji logowania i automatyczne dodawanie kluczy prywatnych SSH do agenta, jeśli jego hasło jest takie samo jak hasło logowania użytkownika. Myślę, że może to być przyczyną różnych zachowań między twoimi systemami.

Dla

$ eval `ssh-agent -s`

Konstrukt do pracy po umieszczeniu w „skryptu startowego”, sesji i ostatecznie terminal gdzie można oczekiwać środowiska, musi być potomkami (o forki exec) tego skryptu. Powodem jest to, że dane wyjściowe ssh-agent -spo ocenie ustawiają zmienne środowiskowe w wywołaniu powłokieval . Z tego miejsca mogą zostać przekazane i mogą zostać zgubione po drodze.

Jeśli więc ssh-agentjest uruchamiany przez skrypt A gdzieś podczas logowania, ale terminal B, w którym uruchamiasz skrypt powłoki, nie jest potomkiem A, to nie możesz zobaczyć środowiska w B.

Jeśli zdarzyło Ci się, że ssh-agentzacząłeś jako systemd --userusługa, być może będziesz musiał zastosować konwencję: Nie pozwól, aby ssh-agent określić zmienne, ale korzystaj ze wspólnej wiedzy podczas uruchamiania agenta i rozpoczynania sesji. Na przykład mój ~/.config/systemd/user/ssh-agent.servicewygląda następująco:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

A w mojej ~/.profilemam linię

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Zauważ, że %tw pierwszym odpowiada ${XDG_RUNTIME_DIR}w drugim.

Uwaga: nie jestem z tego powodu szczęśliwy!

Znalazłem odpowiedź tutaj:

http://www.bernatchez.net/userauth.html

W Ubuntu narzędzie ssh-add nie ładuje plików certyfikatów. Występuje, gdy agent jest tym, który został zaimplementowany przez gnome-keyring. Rozwiązaniem jest zaprzestanie używania komponentu ssh w gnome-keyring. Ponieważ proces inicjowania faktycznie uruchamia prawdziwego agenta ssh, a następnie uruchamia gnome-keyring-ssh.desktop, który blokuje AUTH_SOCKET, aby go przejąć, możemy powrócić do pierwotnego ssh-agent, wyłączając gnome-keyring-ssh.desktop.

Wyłącz gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Dodaj następujący wiersz do pliku pulpitu i zapisz go, a następnie uruchom ponownie:

X-GNOME-Autostart-enabled=false

Wspomniałeś o tym

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

działa zgodnie z życzeniem. Potrzebujesz ich tylko w odpowiednim czasie, w .bash_profile lub .xsession. Dodaj instrukcje debugowania, (date; env|sort) >> /tmp/logaby pomóc Ci zrozumieć, kiedy dokładnie działają.