Konfigurowanie tunelu ssh poprzez wiele hostów i różnych użytkowników

1

Mam następujące połączenia ssh:

    user1@local --> root@machine1 --> root@machine2 --> abc@machine3

Muszę być w stanie połączyć się bezpośrednio z komputera lokalnego z maszyną3:

    [user1@local]$ ssh abc@machine3

W tym momencie czuję się dobrze, jeśli muszę wprowadzić hasła, ale idealnie chciałbym używać kluczy ssh i żadnych połączeń z hasłami.

Jestem w stanie połączyć się z komputerem 1 i komputerem 2 za pomocą sudo, ale połączenie z komputerem 3 nie powiedzie się:

[user1@local]$ sudo ssh abc@machine3
root@machine1.com's password:
root@machine2.com's password:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Mój plik /root/.ssh/config zawiera następujące elementy:

    Host machine1
        HostName machine1.com
        User root
        IdentitiesOnly yes

    Host machine2
        HostName machine2.com
        User root
        ProxyCommand ssh -W %h:%p machine1
        IdentitiesOnly yes

    Host machine3
        HostName machine3.com
        User abc
        ProxyCommand ssh -W %h:%p machine2
        IdentitiesOnly yes

Jestem na OpenSSH_5.3p1 na komputerze lokalnym, dlatego nie mogę używać ProxyJump. Ponadto nie ma obsługi Netcat na komputerach 1,2 i 3.

Kiedy ssh ręcznie, mogę ssh tylko do komputera 3 z komputera 2 jako użytkownik abc, a następnie nie jest wymagane hasło (klucze autoryzowane na komputerze 3 zawierają klucz publiczny z komputera 2). Ręczne połączenie, jak każdy inny użytkownik z maszyną3 z komputera2, powoduje taki sam błąd odmowy uprawnień, jak powyżej.

Masz pomysł, jak uzyskać pożądane połączenie ssh z lokalnego komputera? Czy to jest wykonalne? Po ustawieniu tunelu będę musiał utworzyć kilka plików na maszynie3 i ponownie uruchomić tam usługi - wszystko ze skryptu.

EDYTOWAĆ

Próbowałem ssh z pełnym mówieniem i otrzymałem to:

    [user1@local]$ sudo ssh -v abc@machine3
    OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
    debug1: Reading configuration data /root/.ssh/config
    debug1: Applying options for machine3
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: Executing proxy command: exec ssh -W machine3.com:22 machine2
    debug1: permanently_drop_suid: 0
    debug1: permanently_set_uid: 0/0
    debug1: identity file /root/.ssh/identity type -1
    debug1: identity file /root/.ssh/identity-cert type -1
    debug1: identity file /root/.ssh/id_rsa type -1
    debug1: identity file /root/.ssh/id_rsa-cert type -1
    debug1: identity file /root/.ssh/id_dsa type -1
    debug1: identity file /root/.ssh/id_dsa-cert type -1
    debug1: identity file /root/.ssh/id_ecdsa type -1
    debug1: identity file /root/.ssh/id_ecdsa-cert type -1
    root@machine1.com's password:
    root@machine2.com's password:
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
    debug1: match: OpenSSH_5.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.3
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'machine3.com' is known and matches the RSA host key.
    debug1: Found key in /root/.ssh/known_hosts:4
    debug1: ssh_rsa_verify: signature correct
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
    debug1: Next authentication method: publickey
    debug1: Trying private key: /root/.ssh/identity
    debug1: Trying private key: /root/.ssh/id_rsa
    debug1: Trying private key: /root/.ssh/id_dsa
    debug1: Trying private key: /root/.ssh/id_ecdsa
    debug1: No more authentication methods to try.
    Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Jedynym plikiem, który istnieje w katalogu .ssh na komputerze 3, są klucze autoryzowane.

linux  ssh  ssh-tunnel 
— Lidia
źródło

Odpowiedzi:

1

Fakt, że możesz ssh między maszyną2 a maszyną3 oznacza, że ​​na maszynie2 znajduje się klucz prywatny, który może uwierzytelnić cię na maszynie3.

Możesz skopiować ten klucz prywatny na komputer lokalny i określić jego ścieżkę w ~/.ssh/config: 

Host machine3  
  IdentityFile /path/to/the/key
— David Dai
źródło
0

Po przestudiowaniu istniejącej odpowiedzi w innym pokrewnym pytaniu zrobiłem następujące i niektóre / wszystkie rozwiązały mój problem:

  1. Skopiowano klucze prywatne i publiczne z komputera 1 i komputera 2 na lokalny, o różnych nazwach: /root/.ssh/id_rsa_machine1, /root/.ssh/id_rsa_machine1.pub i /root/.ssh/id_rsa_machine2, /root/.ssh/id_rsa_machine2. pub.
  2. Wygenerowano klucze ssh w systemie lokalnym.
  3. Dodano klucz publiczny z lokalnego systemu do uprawnionych kluczy na maszynie3.
  4. Dodano klucz publiczny z lokalnego do komputera1.
  5. Dodano klucz publiczny z komputera 1 do komputera 2 (komputer 3 miał już klucz publiczny z komputera 2 w uprawnionych_kluczach).

  6. Zmodyfikowano plik /root/.ssh/config na komputerze lokalnym, aby wyglądał następująco:

    Host machine1
    HostName machine1.com
    User root
    IdentityFile /root/.ssh/id_rsa_machine1
    Port 22
    IdentitiesOnly yes

Host machine2
    HostName machine2.com
    User root
    IdentityFile /root/.ssh/id_rsa_machine2
    Port 22
    ProxyCommand ssh -W %h:%p machine1
    IdentitiesOnly yes
    ForwardAgent yes


Host machine3
    HostName machine3.com
    User abc
    ProxyCommand ssh -W %h:%p machine2
    IdentitiesOnly yes
    ForwardAgent yes

Wspomniane pliki tożsamości muszą istnieć na komputerze lokalnym. Mogę teraz ssh bezpośrednio z sudo z lokalnego na machine3 bez monitów o hasło! :-)

Wprowadzono dodatkowe zmiany dla użytkownika 1 na poziomie lokalnym na ssh jako użytkownik 1 na komputerze3 bezpośrednio bez monitów o hasło:

  1. Skopiowano klucze prywatne i publiczne z komputera machine1 i komputera2 do katalogu użytkownika .ssh użytkownika na komputerze lokalnym o następujących nazwach: ~ / .ssh / id_rsa_machine1, ~ / .ssh / id_rsa_machine1.pub i ~ / .ssh / id_rsa_machine2, ~ / .ssh /id_rsa_machine2.pub.
  2. Dodano klucz publiczny dla użytkownika 1 w systemie lokalnym do kluczy autoryzowanych na komputerze3.

Dodano następujące pliki do pliku user1 ~ / .ssh / config:

    Host machine1
        HostName machine1.com
        User root
        IdentityFile ~/.ssh/id_rsa_machine1
        Port 22
        IdentitiesOnly yes

    Host machine2
        HostName machine2.com
        User root
        IdentityFile ~/.ssh/id_rsa_machine2
        Port 22
        ProxyCommand ssh -W %h:%p machine1
        IdentitiesOnly yes
        ForwardAgent yes


    Host machine3
        HostName machine3.com
        User abc
        ProxyCommand ssh -W %h:%p machine2
        IdentitiesOnly yes
        ForwardAgent yes
— Lidia
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.