Die verlockende Einstellung ist AllowTcpForwarding no. Leider deaktiviert sie auch die Weiterleitung, die ein lokaler SSH-SOCKS-Proxy benötigt. Dynamische Weiterleitung ist kein Schlupfloch um die Serverrichtlinie.

Für ein dediziertes Konto trennt OpenSSH mehrere Fähigkeiten. Ein Richtlinienfragment kann lokale Weiterleitung erlauben und gleichzeitig Shell- und Subsystem-Sitzungen verhindern:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

Das Server-Handbuch beschreibt MaxSessions 0 als Einstellung, die Shell-, Login- und Subsystem-Sitzungen verhindert und dabei Weiterleitung zulässt. Binden Sie sie in ein bestehendes authentifiziertes Konto ein; sie ist keine vollständige SSH-Sicherheitskonfiguration.

Nur Weiterleitung ist nicht nur SOCKS

Eine feste lokale Weiterleitung und eine SOCKS-Anfrage können den Server letztlich um dieselbe Art von Zielverbindung bitten. Das Erlauben lokaler Weiterleitung garantiert nicht, dass ein Client eine bestimmte SOCKS-Schnittstelle verwendet hat. Beschreiben Sie das Konto nicht als Durchsetzung einer reinen SOCKS-Nutzung.

PermitOpen kann Ziel-Host-Port-Paare einschränken, wenn eine bestimmte Liste der Anforderung entspricht. Es ist kein allgemeines, hostnamenauflösungsbewusstes Verbot für jedes private Netz. Breitere Adressbeschränkungen können eine geeignete Host-Netzwerkrichtlinie erfordern.

Konto-, Schlüssel- und einbezogene Servereinstellungen können die Weiterleitung weiter einschränken. Ein pauschales Weiterleitungsverbot an anderer Stelle kann eine Fähigkeit entfernen, die dieses Fragment scheinbar erlaubt.

Verwenden Sie das übliche Serververwaltungsverfahren mit einem Wiederherstellungspfad und bewerten Sie dann erlaubte und verweigerte Fähigkeiten getrennt. Das beabsichtigte Ergebnis sind ausdrückliche Weiterleitungsberechtigungen, nicht ein versehentlich verfügbar gelassener interaktiver Login oder ein durch seine eigene Beschränkung deaktivierter Proxy.

Ähnliche Artikel