Ich verwende den folgenden Befehl, um einen SSH-Tunnel zu meinem Ubuntu-Server zu erstellen:
ssh -fNg -L 8888:127.0.0.1:22 -p 1000 username@server-address -v
Dann habe ich den OSX-HTTP- und HTTPS-Proxy auf 127.0.0.1:8888 eingestellt
Und ich habe folgenden Fehler erhalten:
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
Protokoll-Nichtübereinstimmung.
Was ist das Problem und wie kann ich es lösen?
Antwort1
-L 8888:localhost:22 leitet Ihren lokalen Port 8888 an Port 22 des SSH-Servers weiter. Solange dort kein Squid-Server oder ein anderer Proxy läuft, funktioniert dies nicht.
SSH kann einen Socks-Proxy bereitstellen, den Sie zum Durchsuchen Ihres SSH-Tunnels verwenden können.
ssh -fNg -D 8888 -p 1000 username@server-address -v
Richten Sie nach der Verbindung einfach Ihren Proxy ein:
localhost:8888
Antwort2
Sie schreiben: „Ich verwende den folgenden Befehl, um einen SSH-Tunnel zu meinem Ubuntu-Server zu erstellen:
ssh -fNg -L 8888:127.0.0.1:22 -p 1000 Benutzername@Serveradresse -v
OK, Sie benötigen also einen SSH-Server auf Port 1000
OK, also würde das Client-Programm eine Verbindung zu Port 8888 herstellen und alles, was es dorthin sendet, würde an Port 22 weitergeleitet werden (22 ist der Port, der üblicherweise für SSH verwendet wird).
Ich schätze, wenn Sie versuchen würden, SSH innerhalb von SSH zu tunneln, könnte das sinnvoll sein, obwohl mir spontan keine Notwendigkeit dafür einfällt.
Dann habe ich den OSX-HTTP- und HTTPS-Proxy auf 127.0.0.1:8888 eingestellt"
Nein, Sie haben bereits einen Port geöffnet, der mit SSH auf Port 8888 lauscht. Sie können nichts anderes auf diesem Port lauschen lassen.
Wenn Sie den http[s]-Proxy auf Port 22 der Zielmaschine (Serveradresse) setzen und Ihren Webbrowser so konfigurieren, dass er den Proxy 127.0.0.1:8888 verwendet, kann Ihr Webbrowser eine Verbindung zu Port 8888 herstellen und die Verbindung wird an den http-Proxy auf Port 22 der Zielmaschine weitergeleitet. Wenn Sie -L 8888:127.0.0.1:22das tun, bedeutet das, dass Sie etwas haben müssen, das auf Port 22 der Zielmaschine lauscht. Und Sie möchten 22 vielleicht in einen sinnvolleren Wert wie 8080 ändern. Ich habe es nicht getestet, aber ich denke, es würde funktionieren.
Alternativ hat SSH auch eine Option -D, die als SOCKS-Proxy fungiert, der HTTP[s] ausführen kann, aber den Webbrowser anweist, eine Verbindung zu einem SOCKS-Proxy statt zu einem normalen HTTPS herzustellen. Ich nehme also an, dass dann, wie David sagte, ssh -fNg -D 8888 -p 1000 username@server-address -v -fNg und -v natürlich nicht unbedingt erforderlich sind.