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ź
No tak, bo na openwrt masz dropbear, a na vps openssh. Ale i tak się da tak tunel zestawić. Nawet poradnik był tak pisany.
A co myślisz o tej opcji:http://eko.one.pl/forum/viewtopic.php?pid=48814#p48814
Obecnie mój /etc/config/drobbear wygląda następująco:
config dropbear 'global'
option PasswordAuth 'on'
option Port '22'
option max_remote_attempts '10'
Kurcze, już nie mam pomysłów co sprawdzić, gdzie pogrzebać i co wyłączyć żeby to ruszyło...
Ta opcja jest opisana nawet w poradniku u mnie.
Chyba już wszystko wiem...
Na VPSie od host1free root na danym węźle loguje się (jak w moim przypadku) na adres 94.249.206.254, ale jak już utworzy się nowego użytkownika to on już loguje się nie na adres IP root-a tylko na 94.249.249.5 pod którym jest dostępne np www oraz jak się okazuje SSH userów.
Teraz otrzymuję taki komunikat:
root@Gargoyle:~# ssh -f -NT -R 8889:localhost:22 test1@94.249.249.5
ssh: Connection to gargoyle@94.249.249.5:22 exited:Host key mismatch for 94.249.249.5 !
Fingerprint is md5 5f:4b:ee:1c:29:34:22:c0:12:00:71:e1:dc:41:1b:c8
Expected md5 95:18:84:49:7b:25:19:e7:3a:f2:4b:23:09:ed:cf:90
If you know that the host key is correct you can
remove the bad entry from ~/.ssh/known_hosts
root@Gargoyle:~#
jak się domyślam, występuje niezgodność kluczy i należy wygenerować np na Gargoyle nowy klucz i wyeksportować go na VPSa?
Czyli robię wszystko zgodnie z instrukcją o Reverse SSH tunnel i powinno śmigać?
skasuj ~/.ssh/known_hosts po prostu lub wywal z niego ten jeden ip.
Dzięki, pomogło.
Cezary, zrobiłem sobie jeszcze autoryzacje za pomocą kluczy i ich wymianę, do tego oczywiście użyłem również cron-a żeby to zautomatyzować (wykonanie skryptu co 5min). Jest tylko jeszcze jeden problem...
Nie jestem dobry w skryptach, ale wydaje mi się, że skrypt który jest u Ciebie na stronie działa tak, że sprawdza czy wykonało się wykonanie pewnej instrukcji i na tym koniec. Gdy danego procesu/instrukcji niema wtedy oczywiście cron czuwa nad jego uruchomieniem - przy czym nie tworzy nowego, zbędnego procesu, gdy istnieje poprzedni.
Co jednak, gdy skrypt się wykonuje, jest spięty tunel i nagle następuje zrestartowanie VPS-a do którego połączenie się odbywało? Gargoyle widzi, że polecenie się wykonuje i tak jakby nie wznawia połączenia...
Działa to oczywiście z drugiej strony, kiedy to router się zrestartuje, wtedy jak najbardziej cron wykona próbę połaczenia z pozytywnym skutkiem...
Jest sposób/skrypt żeby temu zaradzić?
Ps. no chyba nie dodanie do cron-a restartu routera co np 1h?
Nie. Skrypt nie sprawdza wykonania skryptu, sprawdza czy jest w procesach uruchomiony (pgrep). Jak nie to uruchamia ponownie.
No dobra to co w takim razie zrobić po restarcie serwera VPS? Jak wznowić w tej sytuacji połączenie od strony routera?
Stworzyć skrypt, który cały czas pinguje IP serwera i w razie jego braku restartu tunel od strony routera? Zastanawiam mnie tylko w tym wypadku obciążenie routera... Czy prościej zrobić w cronie restart routera co np 1h.
Co polecasz?
Co chcesz. Własnie skrypt to robił - sprawdzał czy tunel istnieje w pamięci. Możesz pingować po prostu drugą stronę tunelu, jak nie odpowiada to go restartować.
Czy mogę wykorzystać reverse tunnel żeby połączyć się z webowym gui routera?
To tylko przykład, jeśli da się ogarnąć to mój alarm też będzie osiągalny. Proszę, pomóżcie.
Zamiast na port 22 zrób na port 80 czy 443
Cezary to teraz do zwykłego tunelu SSH który mam, wykonuję drugi tunel o np takiej składni:
# ssh -f -NT -R 8889:localhost:22 użytkownik@adres_serwera
+
# ssh -f -NT -R 8888:localhost:80 użytkownik@adres_serwera
i takich tuneli/połączeń może być kilka (np 5)?
A jak to ma wyglądać w skrypcie dodanym do cron-a:
#!/bin/sh
T="ssh -f -NT -R 8889:localhost:22 użytkownik@adres_serwera -i /root/rsa_secret.txt"
pgrep -f "$T" > /dev/null 2>&1 || $T
T2="ssh -f -NT -R 8888:localhost:80 użytkownik@adres_serwera -i /root/rsa_secret.txt"
pgrep -f "$T2" > /dev/null 2>&1 || $T2
tak.
Do Putty dodałem w Tunnels drugi tunel i po SSH mogę się połączyć a gdy wpiszę w przeglądarkę:
127.0.0.1:6666 <---- 6666 to Source port w Putty
otrzymuję komunikat:
Strona internetowa jest niedostępna
Strona internetowa pod adresem http://127.0.0.1:6666/ może być tymczasowo niedostępna lub została na stałe przeniesiona pod nowy adres internetowy.
Błąd 312 (net::ERR_UNSAFE_PORT): Nieznany błąd.
Przeglądarka Google Chrome, VPS nasłuchuje na obydwu portach zestawionych z routera (8888, 8889), ustawienia tunelu jak w poście wyżej...
Co to może być?
To jakieś widzimisie chrome jest, piszą o tym na sieci. FF zobacz.
chromium-browser --explicitly-allowed-ports=6666
Dziękuję, na FF działa, na IE 9 nie, a po wykonaniu "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --explicitly-allowed-ports=6666" Chrome również działa.
A to właśnie to co twórca tego wątku chce zrobić. Zobacz czy zestawienie drugiego tunelu do tego domowego serwera na port tamtego tunelu się uda.
Żeby przekierowane porty były widoczne dla innych komputerów (nie tylko localhost) na serwerze, którego porty tunelujemy dodałem do komendy ssh opcję -g, czyli:
ssh -R 33080:localhost:80 -g login@klient
dzięki temu po wywołaniu adresu klienta z portem 22080 na innym kompie mam dostęp do tunelowanego serwera www.
W konfigu sshd na kliencie trzeba ustawić GatewayPorts yes
Proste, jak nie działą to sprawdzić firewall i przekierowania. Pozdrawiam 
Zapytam tak z ciekawości: w konfigu /etc/config/dropbear opcja GatewayPorts ma mieć dyrektywę YES czy ON, w poradniku oczywiście widnieje yes ale pozostałe opcje są na on...
'1' , 'yes', 'on' lub 'true', odczytywane jest to jako wartość logiczna.
Czy to możliwe, że przy braku internetu (odpięty kabelek internetowy - IP statyczne) cron nie zestawia/wykonuje tunelu/skryptu? Wczoraj odpiąłem internet, zalogowałem się na router wykonałem ps i nigdzie nie było utworzonego tunelu, mimo że ponownie wykonałem restart/enable/start cron-a. Dzisiaj podpiąłem go pod neta i tunel się zestawia - cron działa prawidłowo.
No moment - jaki tunel ma się zestawić jak internetu nie masz bo kabelek wyciągasz?
Zgadza się, ale do crona dodałem wykonanie skryptu i sprawdzałem samo uruchomienie skryptu (które zestawia tunel), czy istnieje w procesach (ps) - samego procesu nie było, dlatego pytam o ten internet, czy może nieć wpływ na samo działanie crona w tym momencie i tym samym próbę ustanowienia tunelu... Wiem, że bez internetu to ciężko by było zestawić tunel
Wydaje mi się, że nawet bez internetu, ale proces/skrypt powinien się wykonać, nie uważasz, w końcu to cron jest za to odpowiedzialny - no chyba że się mylę?
Ale jak ma się zestawić tunel jak nie masz internetu? Przez ssh nie może się połączyć.
Kumam... Czyli router sprawdza sobie czy połączy się przez ssh, jeśli nie to nie ustanawia połączenia (co jest logiczne) i tym samym nie tworzy nowego procesu? Zgadza się?
Po prostu wykonuje skrypt z ssh. A że ono się nie połączy bo internetu nie ma to już inna sprawa.
Pozwolę sobie podpiąć się do tematu.
Próbuje zestawić tunel między dwoma swoimi routerami umownie zwanymi R1 i R2
R1 dostęp do internetu poprzez stałe łącze i stały IP powiedzmy 13.131.313.13
R2 dostęp do internetu poprzez Cyfrowy Polsat i zmienne IP
Gdy korzystam z sieci R2 mam dostęp do R1 poprzez putty na 13.131.313.13:1313
Polecenie:
# ssh -f -NT -R 1313:localhost:22 lamer@13.131.313.13
kończy się odpowiedzią:
ssh: Exited: Error connecting: Connection refused
Gdy w R2 ustawię przekierowanie z portu 1313 na 22 polecenie
# ssh -f -NT -R 1313:localhost:1313 lamer@13.131.313.13
kończy się odpowiedzią:
ssh: Exited: Error connecting: Connection timed out
Na R1 już zrobiłem
# uci set dropbear.@dropbear[0].GatewayPorts=yes
# uci commit dropbear
# /etc/init.d/dropbear restart
i na razie wiszę. Z góry dziękuję za wsparcie.
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