Sie haben ein Passwort eingegeben, um ssh -D zu starten. Damit wurde Ihre SSH-Verbindung authentifiziert. Es wurde jedoch kein passwortgeschütztes SOCKS-Konto für jedes Programm erstellt, das den neuen Listener erreichen kann.

Die dynamische Weiterleitung von OpenSSH bietet einen lokalen SOCKS-Dienst über einen authentifizierten SSH-Transport. Ihre SOCKS5-Behandlung wählt die Methode ohne Authentifizierung; sie ist kein allgemeiner SOCKS-Server mit Benutzername und Passwort.

Für den persönlichen Gebrauch lokal binden:

ssh -N -D 127.0.0.1:1080 [email protected]

Anwendungen auf diesem Rechner verwenden Port 1080, ohne Ihr SSH-Passwort als SOCKS-Passwort einzugeben. Die Dokumentation zur dynamischen Weiterleitung beschreibt den Listener, und der SOCKS-Quellcode von OpenSSH liefert das Authentifizierungsdetail.

Teilen verändert das Problem

Das Binden an eine LAN-Adresse macht den Port über die ursprüngliche lokale Nutzung hinaus erreichbar. Nahe Clients bauen nicht deshalb eigene SSH-Sitzungen auf, weil ihr Datenverkehr über Ihre läuft. Erlaubt das Netzwerk den Zugriff, können diese Clients die nach außen sichtbare Identität Ihres Gateways teilen.

Eine Firewall kann erreichbare Clients einschränken, fügt aber keinen SOCKS-Anmeldeaustausch hinzu. Für getrennte SOCKS-Benutzernamen, Kontingente oder Regeln pro Benutzer wählen Sie einen Server, der diese Funktionen unterstützt. Dante dokumentiert beispielsweise die SOCKS-Authentifizierung getrennt von Client-Adressbeschränkungen.

Das hilft auch bei der Fehlersuche. Ein Client, der auf der SOCKS-Methode mit Benutzername und Passwort besteht, verhandelt mit diesem Listener möglicherweise nicht wie erwartet. Passen Sie die Anwendung an oder wählen Sie einen geeigneten authentifizierten SOCKS-Dienst; wiederholte Versuche mit Ihrem SSH-Passwort adressieren die falsche Anmeldung.

Nur lokale Erreichbarkeit bleibt eine Grenze, die man verstehen sollte, keine Behauptung, dass jeder Prozess auf dem lokalen Rechner demselben Benutzer gehört.

Ähnliche Artikel