Jak mogę skonfigurować tak, że zawsze mogę SSH do mojego systemu przez Internet na dynamicznym IP?

11

Zasadniczo chcę być w stanie zrobić coś takiego jak Teamviewer, gdzie niezależnie od konfiguracji sieci, o ile zarówno mój serwer ssh (Maszyna A), jak i klient ssh (Maszyna B) mają dostęp do Internetu (i jakiś trzeci serwer, Maszyna C ), Mogę uzyskać dostęp - powodem tego jest to, że chcę móc przesuwać maszynę A dookoła, podłączać ją do zasilania, automatycznie łączyć się z jedną z kilku wstępnie skonfigurowanych sieci Wi-Fi (każda niepowtarzalna / inna) , bez skonfigurowania przekierowywania portów lub podobnych w sieci, i być w stanie zalogować się do niego przez Internet z komputera B.

Jak mogę to osiągnąć? Nie mam nic przeciwko skonfigurowaniu czegoś na serwerze ze statycznym adresem IP, aby pomóc w uzgadnianiu, ale nie mam też nic przeciwko serwerowi innej firmy, jeśli coś już istnieje (tak jak w przypadku teamviewer)

edytuj dla jasności: Mam 3 maszyny, AB i C.

A to bezgłowy malinowy pi, który będzie włączany / wyłączany w losowych lokalizacjach, podłącz do wstępnie skonfigurowanej sieci Wi-Fi

B to urządzenie z odpowiednim monitorem, klawiaturą itp., Z którego chcę się połączyć

C to wynajęty serwer AWS, który mam ze statycznym adresem IP, może niezawodnie SSH w B i może zainstalować wszystko, co jest konieczne, aby pomóc B połączyć się z A

użytkownik 2813274
źródło
Czy możesz ssh na 3. maszynie?
Anthon
@Anthon Myślę, że tak, przemianowałem je na AB i C i dodałem dla nich opisy, mam nadzieję, że to wyjaśni
user2813274
kaszel no-ip.com kaszel
Joshua
1
no-ip.com nie pomoże, jeśli zapora sieciowa w Twojej lokalizacji nie zezwala na ruch powrotny!
bobstro
sshBardzo krótko korzystałem z tuneli. Jednak nigdy nie udało mi się zmusić ich do pozostania na nogach autossh; jeśli łącze nadrzędne spadło z jakiegokolwiek powodu, zawsze trzeba je było ponownie uruchomić ręcznie. W końcu założyłem małą VPN dla siebie z OpenVPN, i wykonało to dobrze.
Blacklight Shining

Odpowiedzi:

11

Ponieważ masz maszynę C w Internecie, utwórz tam specjalne konto o nazwie sesame, a na A utworzysz konto z kluczem publicznym / prywatnym, z którego skopiowałeś klucz publiczny na sesamekonto na C.

Możesz teraz zalogować się od A do C, ale zamiast tego:

ssh -N -R 19930:localhost:22 sesame@yourserverC

(możesz połączyć to z instrukcją uśpienia lub np. 10 sekund i owinąć to w niekończącą się pętlę, aby połączenie zostało nawiązane ponownie, jeśli nie działało Wi-Fi)

Z komputera B zwykle loguj się na dowolne konto na C (może być, ale nie musi to być sesamekonto, używam różnych kont). A kiedy będziesz w C, zaloguj się do A, używając:

ssh localhost -p 19930

Możesz oczywiście użyć innej liczby niż 19930.

Możliwe jest uruchomienie ssh -N -R ...z, /etc/rc.localjeśli twój klucz prywatny na A nie jest chroniony hasłem. W takim przypadku należy utworzyć sesameosobne konto z ograniczoną funkcjonalnością, aby w przypadku naruszenia bezpieczeństwa / kradzieży komputera A ryzyko dla serwera C było ograniczone. Dlatego też polecam użyć osobnego konta, aby przejść z B do C.

Rzeczywiście można ustawić powłokę logowania sesamew /etc/passwdcelu /bin/false, więc nie można już korzystać z konta do logowania.

Anthon
źródło
To rozwiązanie różni się od używania TeamViewer, tam serwer służy do otwierania portów, które są następnie przekierowywane w celu bezpośredniej komunikacji. Podobnie jak programy takie jak BitTorrent komunikują się bezpośrednio po znalezieniu komputerów do pobrania (bez konieczności wcześniejszego otwierania portów).
Anthon
Główną różnicą jest to, że w ten sposób CAŁY ruch przechodzi przez serwer C, a C jest używany tylko do ustanowienia łącza, a następnie nie jest używany przez resztę połączenia - nie mam nic przeciwko. Masz dobrą rację, jeśli chodzi o bezpieczeństwo, czy jest coś, co powinienem zrobić w szczególności, aby sezam nie był w stanie nic zrobić na C poza absolutnym minimum logowania? (System RHEL)
2813274
1
@ user2813274 W rzeczywistości w tym scenariuszu cały ruch przechodzi przez C (co pozbawiłoby użyteczność BitTorrenta). Nie jestem pewien, jak daleko możesz ograniczyć sesamekonto na C, może być tak, że możesz uruchomić go /bin/falsejako powłokę logowania (ponieważ ssh tak naprawdę nigdy się nie loguje), lub w inny sposób ograniczyć go, dodając command=parametr w~/.ssh/authorized_keys
Anthon
@ user2813274 W przypadku, gdy nie próbowali sobie pytanie: jeśli masz specjalne konto dla konfigurowania reverse proxy, to można wyłączyć logowania do tego konta poprzez zmianę powłoki logowania do /bin/false.
Anthon
1
@ user2813274 Tak, wypróbowałem to i pozwoliłbym skonfigurować tunel zwrotny (potrzebujesz innego konta, aby dostać się do serwera C, aby to zrobić ssh localhost -p portnum)
Anthon
7

Zainstaluj tunel IPv6 (taki jak Sixxs ) na swoim Raspberry Pi. Będziesz teraz mieć stały statyczny adres IPv6, który będzie dostępny w trybie online za każdym razem, gdy Twoje Pi jest online. Upewnij się, że zabezpieczysz swoje Pi, ponieważ jest ono teraz połączone ze światem.

Jeśli Twój B jest podłączony do sieci IPv6, połącz się bezpośrednio z Pi. Jeśli B nie jest podłączony do sieci IPv6, użyj C jako serwera skokowego, gdzie łączysz się przez IPv4 z C, a następnie ssh przez IPv6 z C do twojego Pi.

garethTheRed
źródło
Podoba mi się to, ponieważ nawet nie wymaga C, jeśli sieci obsługują IPV6, muszę jednak to wypróbować - czy są jakieś problemy, o ile zapory blokują to domyślnie?
user2813274,
1
Sixx zapewnia więcej niż jeden protokół do tunelowania IPv6. Jeśli używasz Anything In Anything (AYIYA), potrzebujesz portu TCP 3874 i portu UDP 5072 otwartych z Pi do Internetu. W sieciach domowych powinno być dobrze; sieci korporacyjne lub kampusowe mogą być inne.
garethTheRed
Instalacja tunelu wydawała się wykonalna, ale wygląda na to, że musiałbym zapisać się do usługi Sixxs, poczekać, aż wrócą do mnie z adresem IP itp. - już nie tak proste - wciąż potencjalnie dobre rozwiązanie, ale ja nie sądzę, że to jest droga, którą zamierzam teraz iść.
user2813274,
1

Zobacz także:

Zastosowana technologia jest taka sama, jak opisana w zaakceptowanej odpowiedzi, ale wykorzystuje niektóre skrypty do automatyzacji rzeczy i uczynienia rozwiązania bardziej ogólnym. To także sprawia, że ​​całe konfiguracje wewnątrz kontenera Docker, dzięki czemu główny system jest bezpieczny na wypadek, gdyby coś zostało naruszone.

Jednak nie zapewnia automatycznego połączenia z punktu A do C, należy go zainicjować ręcznie. Być może możesz trochę dostosować rozwiązanie, aby działało dokładnie tak, jak chcesz.

dashohoxha
źródło
0

Być może musisz użyć innej koncepcji niż ssh lub tunelowanie .. Sugeruję, abyś używał koncepcji przesyłania wiadomości, takiej jak WhatsApp lub telegram .. Ale myślę, że jeśli chcesz użyć czegoś takiego jak vim, nie jest tak dobry jak ssh ..

Telegram ma klienta telegram-cli, który możesz zmodyfikować, aby zaakceptować i wykonać określone polecenie oraz zaimplementować je w raspi ..

Jeśli używasz Telegramu, możesz uprościć swoją sieć i przynajmniej zmniejszyć maszynę C, aby wykonać Hub, ponieważ serwer C jest podtytułowany serwerem wiadomości telegramowych. Telegram już wymyślił iPhone'a i klienta Android, więc nie sądzę, że potrzebujesz B Maszyna też, możesz zainstalować klienta telegramu dla konkretnego systemu operacyjnego, jeśli chcesz ... bezpieczeństwa? wiadomość telegramowa jest zakodowana. Jeśli ktoś chce ddos ​​twoje raspi? najpierw ddos ​​serwer telegramu.

Tak długo, jak twój raspi może łączyć się z serwerem telegramu (po prostu twój raspi łączy się z Internetem), nawet raspi znajduje się za zaporą ogniową / proxy / prywatnym adresem IP / dynamicznym adresem IP, zawsze możesz wykonać zdalne ...

Dzięki tej koncepcji możesz wykonać zdalne sterowanie w dowolnym miejscu i czasie ..

Wicaksono Trihatmaja
źródło
Wat. To niepewne, ufasz jakiejś aplikacji do losowego przesyłania wiadomości, mówisz, że OP powinien zmodyfikować tę aplikację do losowego przesyłania wiadomości, aby działała. To nawet nie zdaje sobie sprawy, że aplikacja do losowego przesyłania wiadomości całkowicie zerwałaby z czymś takim jak vim i miałaby straszne opóźnienia.
Yet Another User
Cóż, jeśli użyjesz go tylko do wysłania polecenia, myślę, że jest w porządku .. jeśli użyjesz go do czegoś takiego jak vim, nie sądzę, że to jest dobre .. dobra rada ..
Zredaguję
Nie sądzę, że tego właśnie chcę, chcę pełnego dostępu do powłoki, a właściwie niczego innego - jeśli chodzi o dozowanie Pi .. Nie jestem naprawdę zaniepokojony, przede wszystkim dlatego, że muszę wykonać specjalną konfigurację, aby nawet sam się z nim
połączę
0

Myślę, że powinieneś przyjrzeć się odwrotnemu przekierowaniu portów ssh. W skrócie, najpierw inicjujesz ssh od A do C, używając poniższej składni, a następnie używasz tego portu do tunelowania z powrotem z C do A. Nie trafisz na zaporę domową A, gdy to zrobisz, ponieważ R-Pi już ma tunel.

ssh -R 2210: localhost: 22 myCoolAwsSite.com

Uwzględnij przy tym konsekwencje bezpieczeństwa. Możesz dodać trochę cujitsu jujitsu, aby połączenie zostało ponownie nawiązane po restarcie.

Hopping Bunny
źródło
Err ... jak to się różni od odpowiedzi Anthona?
user2813274