Czy można tunelować ruch https przez tunel ssh za pomocą standardowych programów ssh?

Czy mogę przekierować ruch https (repozytorium svn) przez tunel ssh.

Problem polega na tym, że usługi korzystające z protokołu https nie działają, jeśli utworzę tylko jeden tunel do nasłuchiwania, np .:

ssh -L 12345:server.com:443 localhost

Czy muszę zrobić coś innego? Celem jest tunelowanie https://PROJECT.googlecode.com/svn/, gdzie PROJECT jest nazwą projektu.

ssh tunnel https

— Juha
źródło

Odpowiedzi:

Połączenie HTTPS można przekierować za pomocą przekierowania portów SSH - jednak weryfikacja certyfikatu SSL / TLS nie powiedzie się w takich przypadkach, gdy nazwa hosta nie jest zgodna:

Łączysz się z https: // localhost: 12345, ale certyfikat serwera zawiera nazwę server.com.

Zamiast bezpośredniego przekazywania połączenia HTTPS uruchomiłbym serwer proxy HTTP / SOCKS na komputerze zdalnym, na którym otwierasz połączenie SSH. Następnie skonfiguruj program, który chcesz tunelować, aby używał tego proxy przez przekierowanie portów. To byłoby czyste rozwiązanie.

Aktualizacja: Wygląda na to, że SVN może korzystać z serwerów proxy HTTP, ale nie z serwerów proxy SOCKS. Jeśli chcesz to zrobić, potrzebujesz dodatkowego „skarpety” w systemie lokalnym. Zobacz Serverfault.com: Jak ustawić proxy dla subversion z tunelem ssh?

— Robert
źródło

Czy faktycznie mogę zastosować takie podejście: dltj.org/article/ssh-as-socks-proxy ? Więc w przypadku kodu googl, miałbym komputer lokalny -> komputer-skarpety -> kod googl. A ten „ssh -D” byłby uruchamiany na komputerze lokalnym: ssh -D 12345 [nazwa użytkownika] @ [socks-computer]. Teraz muszę powiedzieć svn, aby używał proxy na komputerze lokalnym: 12345. Czy potrzebuję czegoś innego?

— Juha,

Fajnie, nie wiedziałem, że OpenSSH zawiera już proxy SOCKS. Zobacz także moją zaktualizowaną odpowiedź.

— Robert,

Możesz obejść problem z certyfikatem HTTPS, dodając hosta zdalnego do pliku hostów lokalnych o adresie IP 127.0.0.1. Następnie możesz faktycznie użyć adresu zdalnego hosta: 12345, ale ruch będzie nadal kierowany do tunelu SSH.

— Juha Palomäki

@ JuhaPalomäki powinieneś dodać to jako odpowiedź

— elhefe

Aby móc obejść problem niedopasowania certyfikatu DNS podczas uzyskiwania dostępu do zdalnego serwera za pomocą tunelu SSH, wykonałem następujące czynności:

Skonfiguruj tunel SSH w putty, aby lokalny port 443 przekazał ruch do zdalnego serwera (L443 : <remote.server.com>:443 )
Zaktualizuj C:\Windows\System32\drivers\etc\hostsplik, aby dodać wpis, taki jak127.0.0.1 <remote.server.com>
Jeśli używasz serwera proxy HTTP (na przykład pracujesz z korporacyjnego serwera proxy), to pomiń <remote.server.com>hosta z systemowego serwera proxy
Teraz możesz uzyskać dostęp do zdalnego adresu URL serwera za pomocą https://<remote.server.com>

— KunalP
źródło