7. TCP/IP Port Forwarding (TCP/IP-Portweiterleitung)

7.1. Requesting Port Forwarding

Eine Partei muss nicht explizit Weiterleitungen von ihrem eigenen Ende in die andere Richtung anfordern. Wenn sie jedoch wünscht, dass Verbindungen zu einem Port auf der anderen Seite zur lokalen Seite weitergeleitet werden, muss sie dies explizit anfordern.

byte      SSH_MSG_GLOBAL_REQUEST
string    "tcpip-forward"
boolean   want reply
string    address to bind (e.g., "0.0.0.0")
uint32    port number to bind

Die address to bind und port number to bind geben die IP-Adresse (oder den Domainnamen) und den Port an, auf dem Verbindungen zur Weiterleitung akzeptiert werden sollen. Einige Zeichenketten, die für address to bind verwendet werden, haben spezielle Semantiken.

"" bedeutet, dass Verbindungen auf allen Protokollfamilien akzeptiert werden sollen, die von der SSH-Implementierung unterstützt werden.
"0.0.0.0" bedeutet, auf allen IPv4-Adressen zu lauschen.
"::" bedeutet, auf allen IPv6-Adressen zu lauschen.
"localhost" bedeutet, auf allen Protokollfamilien zu lauschen, die von der SSH-Implementierung nur auf Loopback-Adressen unterstützt werden ([RFC3330] und [RFC3513]).
"127.0.0.1" und "::1" zeigen das Lauschen auf den Loopback-Schnittstellen für IPv4 bzw. IPv6 an.

Beachten Sie, dass der Client Verbindungen immer noch basierend auf Informationen filtern kann, die in der Öffnungsanfrage übergeben werden.

Implementierungen sollten die Weiterleitung privilegierter Ports nur dann zulassen, wenn der Benutzer als privilegierter Benutzer authentifiziert wurde.

Client-Implementierungen SOLLTEN diese Nachrichten ablehnen; sie werden normalerweise nur vom Client gesendet.

Wenn ein Client 0 als zu bindende Portnummer übergibt und want reply als TRUE hat, weist der Server die nächste verfügbare nicht privilegierte Portnummer zu und antwortet mit der folgenden Nachricht; andernfalls gibt es keine antwortspezifischen Daten.

byte     SSH_MSG_REQUEST_SUCCESS
uint32   port that was bound on the server

Eine Portweiterleitung kann mit der folgenden Nachricht abgebrochen werden. Beachten Sie, dass Kanal-Öffnungsanfragen empfangen werden können, bis eine Antwort auf diese Nachricht empfangen wird.

byte      SSH_MSG_GLOBAL_REQUEST
string    "cancel-tcpip-forward"
boolean   want reply
string    address_to_bind (e.g., "127.0.0.1")
uint32    port number to bind

Client-Implementierungen SOLLTEN diese Nachrichten ablehnen; sie werden normalerweise nur vom Client gesendet.

7.2. TCP/IP Forwarding Channels

Wenn eine Verbindung zu einem Port kommt, für den Remote-Weiterleitung angefordert wurde, wird ein Kanal geöffnet, um den Port zur anderen Seite weiterzuleiten.

byte      SSH_MSG_CHANNEL_OPEN
string    "forwarded-tcpip"
uint32    sender channel
uint32    initial window size
uint32    maximum packet size
string    address that was connected
uint32    port that was connected
string    originator IP address
uint32    originator port

Implementierungen MÜSSEN diese Nachrichten ablehnen, es sei denn, sie haben zuvor eine Remote-TCP/IP-Portweiterleitung mit der angegebenen Portnummer angefordert.

Wenn eine Verbindung zu einem lokal weitergeleiteten TCP/IP-Port kommt, wird das folgende Paket an die andere Seite gesendet. Beachten Sie, dass diese Nachrichten auch für Ports gesendet werden DÜRFEN, für die keine Weiterleitung explizit angefordert wurde. Die empfangende Seite muss entscheiden, ob sie die Weiterleitung zulässt.

byte      SSH_MSG_CHANNEL_OPEN
string    "direct-tcpip"
uint32    sender channel
uint32    initial window size
uint32    maximum packet size
string    host to connect
uint32    port to connect
string    originator IP address
uint32    originator port

Die host to connect und port to connect geben den TCP/IP-Host und Port an, mit dem der Empfänger den Kanal verbinden soll. Der host to connect kann entweder ein Domainname oder eine numerische IP-Adresse sein.

Die originator IP address ist die numerische IP-Adresse der Maschine, von der die Verbindungsanfrage stammt, und der originator port ist der Port auf dem Host, von dem die Verbindung stammt.

Weitergeleitete TCP/IP-Kanäle sind unabhängig von Sitzungen, und das Schließen eines Sitzungskanals impliziert in keiner Weise, dass weitergeleitete Verbindungen geschlossen werden sollten.

Client-Implementierungen SOLLTEN direkte TCP/IP-Öffnungsanfragen aus Sicherheitsgründen ablehnen.