SSH ForwardAgent wiele przeskoków

Przez ostatnie 2 godziny szukałem rozwiązania następującego problemu bez powodzenia.

Rozwój:

Używam uwierzytelniania publickey do łączenia się z moimi serwerami. Używam przekazywania ssh-agent, aby nie musieć zarządzać kluczami publicznymi / prywatnymi.

Powiedzmy, że mam serwery A, B and C.

Działa to bardzo dobrze, jeśli łączę się z LOCAL ---> A ---> B.

Działa to również bardzo dobrze, jeśli to robię LOCAL ---> A ---> C.

Teraz, jeśli spróbuję LOCAL ---> A ---> B ---> C, SSH nie może się połączyć B to C.

Warto zauważyć: łączę się z serwerem A jako płynność, natomiast łączę się z serwerem B jako root. Łączenie się z serwerem B jako płynność rozwiązuje problem, ale nie jest to dla mnie opcja.

Zgodnie z zaleceniem użytkownika za ssh -Akażdym razem upewniam się, że przekazywanie agentów jest włączone.

Znalazłem jedno podobne pytanie, na które nie ma odpowiedzi: czy można łączyć przekazywanie agentów ssh przez wiele przeskoków?

Według @Zoredache tutaj: /server//a/561576/45671 Muszę tylko dostosować konfigurację klienta w każdym systemie pośrednim. Co, jak sądzę, zrobiłem.

— płynność
źródło

Rozważ użycie ProxyCommandprzeskoku (jak wyjaśniono tutaj ) zamiast przekazywania agenta SSH. Za swoje podejście musisz zaufać wszystkim komputerom w łańcuchu, ponieważ mogą one (ab) używać twoich kluczy prywatnych. Podoba mi się również podejście ProxyCommand o wiele lepiej, ponieważ sprawdzanie znanych hostów odbywa się lokalnie, a ponadto możesz skonfigurować łańcuch w konfiguracji SSH, dzięki czemu możesz użyć jednego polecenia do połączenia z C.

— gertvdijk

Niestety nie mogę użyć proxyCommand. Mimo względów bezpieczeństwa naprawdę muszę użyć forwardAgent.

— płynność

@liquidity mogę zapytać, dlaczego nie chcesz używać proxyCommand? Mam ten sam problem i, jak rozumiem, proxyCommand jest bardziej bezpieczne. Więc zastanawiam się, którego użyć ...

— grep

Aby przekazywanie agentów działało przez wiele przeskoków, wystarczy dostosować konfigurację klienta w każdym systemie pośrednim, aby przekazywanie agentów było możliwe.

Może to być tak proste, jak upewnienie się, że masz /etc/ssh/ssh_configto skonfigurowane. Ale jeśli masz konfiguracje dla poszczególnych klientów ~/.ssh/config, może być konieczne dostosowanie tych ustawień.

Host *
    ForwardAgent yes

Możesz sprawdzić, czy nastąpiło przekazanie agenta lub czy wystąpił błąd, jeśli tylko dodasz -vopcję.

$ ssh -v issc@server1
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/zoredache/.ssh/config
...
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
Linux server1 3.11-0.bpo.2-amd64 #1 SMP Debian 3.11.8-1~bpo70+1 (2013-11-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Dec 15 20:39:44 2013 from 10.2.4.243
issc@server1:~$

Sprawdź także, czy masz poprawny zestaw zmiennych środowiskowych.

issc@server1:~$ export | grep SSH_AUTH
declare -x SSH_AUTH_SOCK="/tmp/ssh-7VejOmKtNv/agent.57943"

— Zoredache
źródło

Warto wspomnieć o opcji -A dla ssh jako szybkiej i brudnej alternatywy dla opcji ssh_config lub ~ .ssh / config. - Przekazywanie połączenia agenta uwierzytelniającego.

— dmourati,

Na każdym kroku, można użyć ssh-add -lnotować klucze ssh myśli może uzyskać co poprzez swojego agenta. Upewnij się, że przekazujesz go przy każdym połączeniu!

— MikeyB,

Dzięki! Pamiętaj również, że jeśli wszystko zostanie wykonane poprawnie, nie będziesz musiał ręcznie uruchamiać agenta ssh na ostatnim serwerze. Rozpocznie się automatycznie, jeśli zobaczysz wiersz Requesting authentication agent forwarding.w wynikach debugowania. Jeśli próbowałeś .bash_profileuruchomić ssh-agent, usuń go stamtąd, w przeciwnym razie agent uruchomi się ponownie bez żadnych tożsamości.

— 2upmedia