Próbowałem skonfigurować prawidłową konfigurację, aby otworzyć połączenie z drugim komputerem, przechodząc przez inny i używając id_rsa (który prosi mnie o hasło), aby połączyć się z trzecim komputerem.

Zadałem to pytanie na innym forum, ale nie otrzymałem odpowiedzi, którą można by uznać za bardzo pomocną.

Problem, lepiej opisany, wygląda następująco:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Jestem w stanie wykonać całe połączenie przy użyciu pseudo-tty:

ssh -t inter ssh user2@final

(poprosi mnie o hasło do pliku id_rsa, który mam na komputerze „inter”)

Jednak w celu przyspieszenia rzeczy chciałbym ustawić mój plik .ssh / config, aby móc po prostu połączyć się z maszyną „końcową” za pomocą:

ssh final

Do tej pory mam - co nie działa - w moim pliku .ssh / config:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Plik id_rsa służy do łączenia się z komputerem środkowym (nie wymaga to wpisywania hasła), a plik id_rsa_2 służy do łączenia się z komputerem „końcowym” (ten żąda hasła).

Próbowałem mieszać niektóre pola LocalForwardi / lub RemoteForwardumieszczać pliki id_rsa zarówno na pierwszym, jak i drugim komputerze, ale nie mogłem odnieść sukcesu bez żadnej konfiguracji.

PS: wątek, z którego próbowałem uzyskać pomoc:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

METODA 1 (użyj klawisza ssh na inter)

Jeśli chcesz zachować przepływ uwierzytelniania

local -- authenticate --> inter -- authenticate (ask password) --> final

Nie można tego zrobić za pomocą .ssh / config proxyhost.

Potrzebujesz aliasu powłoki bash (mam nadzieję, że używasz bash).

W ~/.bashrcdodaj następujący wiersz

alias ssh-final='ssh -t inter ssh user2@final.com'

W wierszu polecenia wpisz następujące

ssh-final

finalsekcja w ~/.ssh/confignie jest używany.

Szczegóły połączenia (1)

ssh -t inter ssh user2@final.com można wyświetlić w następujący sposób

local# ssh inter
inter# ssh user2@final.com

localtylko „rozmawia” z inter. Nie ma bezpośredniego ani pośredniego połączenia ssh pomiędzy locali final. localwyświetla tylko wynik działania ssh user2@final.com.

METODA 2 (użyj klucza ssh na komputerze lokalnym)

Uwierzytelnianie za pomocą tego samego klucza SSH

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Skopiuj lokalnie ~/.ssh/id_ras.pub do

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Szczegóły połączenia (2)

tunelowanie ssh

Zanim przejdziemy do szczegółów ProxyCommand, spójrzmy na następujący przykład

Krok 1, w oknie terminala 1

local# ssh inter -L 2000:final.com:22

Krok 2, w oknie terminala 2

local# ssh localhost -p 2000

W terminalu 1 tunel jest ustawiony między portem lokalnym 2000 a portem final.com 22. Wszystko, co zostanie wysłane do portu lokalnego 2000, zostanie przekierowane do portu final.com 22 i odwrotnie.

W terminalu 2 ssh łączy się z lokalnym portem 2000, ale w rzeczywistości komunikuje się z portem final.com 22, którym jest sshd.

Dzięki tunelowaniu lokalny klient ssh w kroku 2 jest bezpośrednio połączony z final.com sshd.

„Wyjście” lokalnego portu 2000 to „surowy” ruch demona ssh.

Częstym zastosowaniem takiego tunelu jest dostęp do wewnętrznego serwera WWW lub serwera e-mail. Poniżej znajduje się przykład serwera WWW

local# ssh inter -L 2000:final.com:80

W przeglądarce użyj następującego adresu URL

http://localhost:2000

Dwa punkty końcowe tunelu to lokalny port 2000 i final.com port 80.

Ruch przychodzący i wychodzący z punktu końcowego tunelu „AS IS”. Nazwijmy ten „surowy” ruch.

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

ProxyCommandWziąć to krok dalej. Pomija etap tworzenia portu lokalnego i łączy się z nim.

Klient ssh wykona dowolną komendę ProxyCommandi potraktuje wynik tej komendy jako „nieprzetworzony” ruch. Trzyma lokalny punkt końcowy, a następnie nawiązuje z nim połączenie ssh.

Dlaczego jedna praca nie działa?

Następujące polecenie

ssh inter nc final.com 22

w zasadzie oznacza (1) połączenie z inter, a następnie (2) włączenie interpolecenia uruchomienia nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

Więc nc final.com 22będzie łączyć się final.com portu 22, wydrukować cały ruch przychodzący do stdout, stdin i wysłać wszystko na drugą stronę. Jest to „tunel” między nc stdin / out a portem final.com 22.

Ponieważ ncjest uruchamiany w ramach sesji ssh, cały jego stdout jest przekazywany z powrotem do klienta ssh jako „surowy” ruch. A klient ssh może przekazywać ruch do nc stdin, który skończy na porcie final.com 22.

Przez powyższy „tunel” lokalny klient ssh rozpocznie sesję ssh final.combezpośrednio.

Następujące polecenie

ssh -t inter ssh user2@final.com

nie działa, ProxyCommandponieważ wyjście z niego nie jest „surowym” ruchem z demona ssh. Jest to standardowe wyjście klienta ssh . Rozmowa z klientem oznacza brak działalności.

Uwierzytelnianie za pomocą innego klucza SSH (oryginalna konfiguracja OP)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Skopiuj lokalnie ~/.ssh/id_ras.pub do

/home/user1/.ssh/authorized_keys in `inter`

Skopiuj lokalnie ~/.ssh/id_ras_2.pub do

/home/user2/.ssh/authorized_keys in `final`

Oba powyższe umożliwią następujące użycie

local# ssh final

Dodatkowe sprawdzanie

Używaj pełnych słów

local# ssh -v final

To powinno pomóc w identyfikacji problemu ssh.

Sprawdź nc

ProxcyCommandwykonuje ncsię inter. Sprawdź, czy ncjest faktycznie dostępny w dniuinter .

local# ssh inter
inter# nc final.com 22

Sprawdź, czy klucz RSA jest poprawnie skonfigurowany

Jeśli mają być używane różne klucze interi final, na komputerze lokalnym powinny istnieć następujące pliki

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Ponieważ możesz interjuż ssh , sprawdź konfigurację klucza na final. Z lokalnego komputera

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Powinieneś zobaczyć id_rsa_2.pubtam zawartość .

Nie widziałem na liście żadnych błędów ani instrukcji ssh -v, które pomogłyby zobaczyć, gdzie się rozłącza.

Hej, masz prawie rację - najlepszym i najbezpieczniejszym sposobem jest posiadanie obu kluczy na komputerze lokalnym. Następnie użyłbyś przekierowania agenta ssh do połączenia, zamiast zostawiać klucze na pośrednich etapach. Zaletą jest także to, że hasło należy wpisywać tylko raz podczas logowania.

Jeśli masz nowoczesny / przyjazny dla użytkownika system operacyjny, taki jak ubuntu (na komputerze lokalnym), nie powinno to działać bez żadnego * masowania *. Celowo zostawiłem plik tożsamości, nie będziesz go potrzebować.

Twój plik konfiguracyjny wyglądałby tak:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Jeśli nie, wykonaj następujące kroki, aby upewnić się, że ssh-agent działa:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Tutaj jest ładny przewodnik wyjaśniający, jak to działa .