Jak połączyć SSH z maszyną A za pośrednictwem B w jednym poleceniu?

Chcę uzyskać dostęp do komputera, powiedzmy komputer A, który jest oparty na sieci mojej uczelni. Jednak ten komputer jest dostępny tylko przez wewnętrzną sieć uniwersytetu, więc nie mogę używać SSH do tego komputera bezpośrednio z domu.

Oto co teraz robię:

1. Zaloguj się do innego komputera uniwersyteckiego, powiedzmy komputer B

   (Ta maszyna B jest dostępna przez SSH z mojego komputera domowego.)

2. Użyj SSH na B, aby połączyć się z A.

Czy istnieje sposób, aby to zrobić szybciej? Używanie tylko jednego polecenia ssh.

Tak, używając ProxyCommandw konfiguracji SSH.

Utwórz plik konfiguracyjny SSH w swoim katalogu domowym (chyba że chcesz zrobić to dla całego systemu) ~/.ssh/config:

Host unibroker          # Machine B definition (the broker)
Hostname 12.34.45.56    # Change this IP address to the address of the broker
User myusername         # Change this default user accordingly 
                        # (`user@unibroker` can overwrite it)

Host internalmachine    # Machine A definition (the target host)
ProxyCommand ssh -q unibroker nc -q0 hostname.or.IP.address.internal.machine 22

Teraz możesz bezpośrednio dotrzeć do maszyny A.

ssh user@internalmachine

Zauważ też, że teraz masz dla niego pojedynczą nazwę docelową hosta SSH, możesz jej używać również w innych aplikacjach. Na przykład:

• SCP do kopiowania plików.

  scp somefile user@internalmachine:~/
  

• W aplikacjach GUI:

  użyj sftp://user@internalmachine/jako lokalizacji do przeglądania na maszynie.

  Oparte na KDE (Dolphin): użyj fish://user@internalmachine/

Notatki

Zmień hostname.or.IP.address.internal.machinei port ( 22) na maszynie, do której chcesz dotrzeć, tak jakbyś z unibrokermaszyny.

W zależności od wersji netcata na hoście unibrokera -q0opcję tę należy pominąć. W odniesieniu do uwierzytelnienia; w zasadzie konfigurujesz dwa połączenia SSH ze stacji roboczej. Oznacza to, że zarówno host unibrokera, jak i host maszyny wewnętrznej są weryfikowane / uwierzytelniane jeden po drugim (zarówno dla pary kluczy / hasła, jak i weryfikacji klucza hosta).

Wyjaśnienie

Takie podejście z użyciem ProxyCommandi „netcat” jest tylko jednym ze sposobów na to. Podoba mi się to, ponieważ mój klient SSH komunikuje się bezpośrednio z maszyną docelową, dzięki czemu mogę zweryfikować klucz hosta od mojego klienta i mogę korzystać z uwierzytelniania mojego klucza publicznego bez używania innego klucza w brokerze.

Każdy Hostokreśla początek nowej sekcji hosta. Hostnameto docelowa nazwa hosta lub adres IP tego hosta. Userjest to, co podasz jako część użytkownika ssh user@hostname.

ProxyCommandbędzie używany jako rura do maszyny docelowej. Poprzez użycie SSH do pierwszego komputera i bezpośrednie skonfigurowanie ncstamtąd prostego „netcat” ( ) do celu, jest to po prostu zwykły tekst przekazywany do wewnętrznego komputera od brokera pomiędzy nimi. Te -qopcje są do milczenia żadnego wyjścia (tylko osobiste preferencje).

Upewnij się, że na brokerze jest zainstalowany program Netcat (zwykle dostępny domyślnie w systemie Ubuntu) - netcat-openbsd lub netcat-traditional .

Pamiętaj, że nadal używasz SSH z szyfrowaniem dwa razy tutaj. Podczas gdy kanał Netcat jest zwykłym tekstem, twój klient SSH na twoim komputerze skonfiguruje inny zaszyfrowany kanał z ostateczną maszyną docelową.

Wskakuj za jednym razem

Oczywistą alternatywą dla podejścia ProxyCommand, które podałem w mojej innej odpowiedzi, byłoby „przeskakiwanie” bezpośrednio do maszyny docelowej:

ssh -t user@machineB ssh user@machineA

Zwróć uwagę -tna pierwsze sshpolecenie. Bez tego zawiedzie:

Pseudo-terminal will not be allocated because stdin is not a terminal.
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
[...]

Wymusi to przydzielenie prawdziwego TTY

Minusem tego jest to, że teraz cała konfiguracja, weryfikacja i uwierzytelnianie odbywa się na komputerze B, co tak naprawdę nie lubię w mojej sytuacji ze względów bezpieczeństwa. Podoba mi się moja para kluczy na własnym komputerze oraz uwierzytelnianie i weryfikacja docelowej maszyny na własnym komputerze. Ponadto można używać interaktywnej powłoki tylko dla SSH, więc nie będzie to obsługiwać innych narzędzi, takich jak SCP lub menedżer plików GUI.

Ze wszystkich wyżej wymienionych powodów zdecydowanie zalecam podejście ProxyCommand , ale w przypadku szybkiego połączenia działa to dobrze.

Możesz użyć -Jopcji wiersza poleceń:

ssh -J user@machineB user@machineA

Od man ssh:

-J [user@]host[:port]
     Connect to the target host by first making a ssh connection to
     the jump host and then establishing a TCP forwarding to the
     ultimate destination from there.  Multiple jump hops may be
     specified separated by comma characters.  This is a shortcut to
     specify a ProxyJump configuration directive.

Został wprowadzony w wersji OpenSSH 7.3 (wydanej w sierpniu 2016 r.). Jest dostępny w wersji Ubuntu 16.10 i nowszych.

Spróbuj użyć

Host <visible hostname alias>
        Controlmaster auto
        User <user>
        hostname <visible hostname>
        port <port>
        IdentityFile ~/.ssh/<id file>

Host <private LAN hostname alias>
     ProxyCommand ssh -q -W <private LAN hostname>:<private LAN port> <visible hostname alias>

w ~ / .ssh / config i zrób to wszystko jednym strzałem z kluczami znajdującymi się tylko na twoim komputerze.

To bardzo pomocna sugestia. Po wielu godzinach gadania znalazłem tę notatkę i potwierdziłem, że działa ona dokładnie tak, jak zostało to udokumentowane. Aby połączyć się przez MachineA z MachineB, ze zdalnego komputera C:

np .: [xuser @ machineC ~] ssh -t MachineA ssh MachineB

„-T” jest krytyczne, ssh zawiedzie, jeśli nie jest obecne. Zostaniesz dwukrotnie zapytany, najpierw o hasło na MachineA, a następnie drugi raz na MachineB. Zauważ też, że zakłada się, że na wszystkich trzech komputerach zdefiniowano użytkownika „xuser”. Jeśli nie, po prostu użyj składni ssh: „yuser @ MachineA ...”. Zauważ też, że możesz użyć kropkowanych quad surowych adresów IP, jeśli chcesz. Jest to przydatne, jeśli łączysz się przez prywatną sieć lokalną, która korzysta z adresów IP nie narażonych na świat - tj. nie w lokalnym pliku hosta ani w żadnym DNS. Aby pobrać plik z MachineB, na zdalną maszynę C, możesz scpować z MachineB na MachineA, a następnie z MachineA na zdalną maszynę C. (Np. Zdalna maszyna C może pingować MachineA, ale nie MachineB.) Zastrzeżenie: Testowałem z Fedorą i WindowsXP, MachineA to XP-box z ICS (Udostępnianie połączenia internetowego), podczas gdy MachineB i zdalna maszyna C są pudełkami Fedory-Linux. Ta sugestia rozwiązała dla mnie kluczowy problem - tj. ograniczony, monitorowany zdalny dostęp do mojej zdalnej witryny LAN. Uwaga: po „wylogowaniu” z MachineB powinieneś zobaczyć dwa „Połączenie z xxx.xxx.xxx.xxx zamknięte”. wiadomości.

ProxyCommand to czyste rozwiązanie w przypadku, gdy pozwalasz na dostęp do powłoki w obu systemach. Chcieliśmy zapewnić zdalnym użytkownikom dostęp do komputera wewnętrznego (A) za pośrednictwem brokera (B), ale bez umożliwienia użytkownikowi dostępu do powłoki B w celu zwiększenia bezpieczeństwa. To działało:

Zamień powłokę logowania

Zastąp powłokę logowania (użyj chsh) dla extuserbrokera następującym skryptem (przechowywanym w pliku):

#!/bin/sh   # this is essential to avoid Exec format error
ssh internaluser@A

Pod warunkiem, że nie skonfigurowano hasła logowania w extuser @ B dla użytkownika zdalnego i w internaluser @ A dla extuser @ B, wówczas wykonanie następującego polecenia spowoduje bezpośrednie przejście użytkownika zdalnego do A

ssh extuser@B

Wskazówka : Przed przejściem do niestandardowej powłoki logowania należy utworzyć niezbędną konfigurację logowania bez hasła za pomocą autoryzowanych kluczy w extuser @ B. Po zmianie, ponieważ to konto jest niedostępne dla nikogo przez powłokę, tylko sudoer @ B może dokonać zmian w pliku autoryzowanych_kluczy, edytując je bezpośrednio.

sudo vi ~extuser/.ssh/authorized_keys
sudo touch ~extuser/.hushlogin

Ostatnim wierszem jest wyłączenie wyświetlania banera logowania z B, aby zdalny użytkownik miał przejrzysty dostęp do A.

Masz na myśli, że potrzebujesz kilku zworek :)

Ostatnio spotkałem ten problem z jumper1 jumper2 i moją maszyną końcową, tak jak w przypadku mojego sola

skrypt lokalny:

#!/bin/bash
sshpass -p jumper1Passwd ssh -t jumper1@jumper1IP ./Y00.sh

następnie na 1. zworce (która jest moim routerem) umieściłem skrypt o nazwie Y00.sh:

ssh -tt jumper2@jumper2 -i ~/.ssh/id_rsa sshpass -p finalPassWord ssh -tt final@final

Możesz je zastąpić swoim adresem IP i hasłami, powodzenia!