Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Gargoyle by obsy, WRT160NL i SSH Reverse tunnel
Strony Poprzednia 1 2 3 4 5 6 7 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Poczekaj, a R1 nie słucha na domyślnym porcie 22 tylko na 1313, tak? To do ssh podaj jeszcze argument -p 1313
ssh -f -NT -R -p 1313:localhost:22 lamer@13.131.313.13
ssh: Exited: Bad TCP forward '-p'
Nie...
ssh -p 1313 -f -NT -R -1313:localhost:22 lamer@13.131.313.13
No tak, gramatyka nie jest moją mocną stroną. 
Działa. DZIĘKUJĘ!!!
A tom daleko uszedł.
scp klucz_pub.txt lamer@13.131.313.13:~/.ssh/.
/usr/bin/dbclient: Exited: Error connecting: Connection refused
lost connection
Teraz to druga strona Ci odrzuca połączenie.
Druga strona to znaczy R2?
Mam wybrać inny port niż 22 i zrobić przekierowanie?
ssh -p 1313 -f -NT -R 1313:localhost:22 lamer@13.131.313.13
lamer@13.131.313.13's password:
ssh: Remote TCP forward request failed (port 1313 -> localhost:22)
Ciekawe. Raz mi się to pokazuje a raz nie.
No jeżeli zwykłe połączenie ssh/scp nie chce to stanowczo Cię już ta druga strona nie lubi 
Jeżeli masz do niej inny dostęp to zobacz czy proces ssh tam nie wisi.
Ja siedzę lokalnie na R2 i mam dostęp przez sieć do R1.
ps w
4401 root 1192 S ssh -p 1313 -f -NT -R 1313:localhost:22 lamer@13.131.313.13
No wreszcie się udało, ale pozostał mały, ale zasadniczy feler.
Po każdym restarcie trzeba podać hasło, co podważa sensowność zdalnego dostępu.
Co może być nie tak z klucz_pub.txt?
A gdzie położyłeś klucze?
Na R2 na root są klucz_pub. txt i rsa_secret.txt
Na R1 ~/.ssh/ authorized_keys
I dropbear na obu? To żle, w /etc/dropbear/authorized_keys mają być klucze.
Nie mam problemu z łączeniem się z serwera R1 do klienta R2, ale zestawieniem tunelu z klienta.
Wtedy pyta się o hasło.
Mam skopiować authorized_keys z R1 na R2 do w/w lokalizacji?
Jeżeli na docelowym jest dropbear to tak. On tam szuka kluczy, nie w .ssh
Noooo tak.
Teraz mogę iść spać. Dziękuję i dobranoc.
P.S.
Gwoli ścisłości to authorized_keys należało umieścić w etc/dropbear/ serwera, czyli w moim przypadku R1
Oddaliłem się od R2 na znaczną odległość, będąc pewny, że skrypt, który ma dbać o ciągłość pracy tunelu ja faktycznie zapewni.
Okazuje się, że tunel się zestawia sam, owszem ale tylko po reboocie, a po upłynięciu nieznanego mi czasu nagle nie mam już do R2 dostępu z R1. Na 99% mam pewność, że jakbym lokalnie zapodał na R2 "ps w" to pokaże mi, że mój ssh działa.
lamer@R1:~# ssh -p 1313 root@127.0.0.1
ssh: Exited: Error connecting: Connection refused
Jak najlepiej rozwiązać n/w problem:
Gargoyle z Aero2 które będzie się łączyło do VPS-a w sieci po SSH Reverse tunnel. Jak zrobić, by w chwili cogodzinnego rozłączenia internetu Gargoyle ponownie wznawiało połączenie do VPSa?
Przychodzi mi do głowy takie rozwiązanie:
- skrypt sprawdzający co 10 sek. ping np na Google, gdy pingi dochodzą wykonuje skrypt, gdy jest brak internetu/pingu zabija proces (po nazwie) wcześniej utworzonego połączenia ssh-tunelu/skryptu
- skrypt do crona i ma hulać.
Co myślicie o takim rozwiązaniu? Czy pingi w określonym odstępie czasu nie zarżną WRT160NL?
przetestuj - co więcej powiedzieć - w końcu Ty go będziesz używać, Ty wiesz jak VPS ustawiony, na co i jak reaguje lub nie. Znajdź słabe/mocne strony tego pomysłu - a jak zaczną się problemy wtedy napisz co i jak - wtedy zapewne ktoś zareaguje.
Pierwsze co mi przychodzi na myśl to po co, co 10 sek. ?
@wojciech_69: gotowiec jest na eko.one.pl zaczerpnięty z tego forum...
Dlatego, że po rozłączeniu internetu mniej więcej tyle czasu potrzebuje router-modem żeby wznowić połączenie (jeśli nie zachodzą inne nieprzewidziane trudności, choćby nawet przeciążenie sieci które wydłuża okres oczekiwania na ponowne połączenie).
Jeżeli przerwa będzie dłuższa to jak dobrze kumam, router połączy się ponownie do internetu, skrypt sprawdzi, że połączenie jest i nie wykona-zestawi tunelu, który poprzednio został zerwany...
Więc niech skrypt wykrywa ten fakt po prostu a cron i to niech sprawdza - jak zajdzie taka sytuacja ma zareagować operacjami dążącymi do zestawienia tunelu na nowo. Skoro Cezary pisze, że jest już gotowiec to po co wywarzać otwarte drzwi - najwyżej można mu nowe "zawiasy dorobić" czy cuś jak się nada.
Cezary chodzi ci może o heartbeat czy może jakiś skrypcik z "przydatne skrypty"?
Ps. jeśli o heartbeat to jak wiesz wymagana jest stronka www i tu jest kolejny problem, do przebrnięcia ale jednak...
Nie, http://eko.one.pl/?p=openwrt-sshtunnel#automatyzacja
Najciemniej pod latarnią... Cezary czy interwał czasowy nie lepiej zrobić mniejszy, czy wg Ciebie ten czas będzie idealny do ewentualnego wznowienia połączenia/tunelu?
Nie jestem znawcą ale jak mniemam to ten skrypcik działa tak, że sprawdza zmienną "$T"i jak się powiela to poprzedni proces zabija, żeby nie stworzyć n-tej liczby procesów i ponownie zestawia tunel?
Strony Poprzednia 1 2 3 4 5 6 7 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Gargoyle by obsy, WRT160NL i SSH Reverse tunnel
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc