Worauf beziehen sich die Kanalnummern in der ssh-Fehlermeldung?

Womit stimmen die Kanalnummern im folgenden Beispiel überein? Welche sind auf dem Server? Welche sind auf dem Client?

  $ ssh -L1570:127.0.0.1:8899 root@thehost
    Password:
    Last login: Fri Aug  9 13:08:44 2013 from theclientip
    Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
    You have new mail.
    # channel 2: open failed: administratively prohibited: open failed
    channel 3: open failed: administratively prohibited: open failed
    channel 2: open failed: administratively prohibited: open failed

Der ssh-Client läuft unter Windows 7 und auf dem Server läuft ein Tomcat-Server auf Port 8899.

Tomcat lauscht nicht auf 127.0.0.1 auf dem Remote-Computer. Wenn ich den Befehl ändere ssh -L1570:thehostpublicip:8899 root@thehost, funktioniert die Portweiterleitung. Ich weiß also, dass die Portweiterleitung auf dem Server einwandfrei funktioniert.

Meine sshd-Konfigurationsdatei enthält die folgenden zwei Zeilen:

# Port forwarding
AllowTcpForwarding yes

# If port forwarding is enabled, specify if the server can bind to INADDR_ANY.
# This allows the local port forwarding to work when connections are received
# from any remote host.
GatewayPorts yes

Ich versuche, die Portweiterleitung für einen anderen Prozess als Tomcat einzurichten, und es werden Fehlermeldungen angezeigt, die denen oben ähneln. Daher versuche ich, die Bedeutung der Fehlermeldungen zu verstehen.

Aus der Dokumentation des SSH-Protokolls zu den Kanälen:

Alle Terminalsitzungen, weitergeleiteten Verbindungen usw. sind Kanäle. Jede Seite kann einen Kanal öffnen. Mehrere Kanäle werden zu einer einzigen Verbindung gemultiplext.

Kanäle werden an jedem Ende durch Nummern gekennzeichnet. Die Nummer, die sich auf einen Kanal bezieht, kann auf jeder Seite unterschiedlich sein. Anfragen zum Öffnen eines Kanals enthalten die Kanalnummer des Absenders. Alle anderen kanalbezogenen Nachrichten enthalten die Kanalnummer des Empfängers für den Kanal.

Kanäle sind durchflussgesteuert. Es können keine Daten an einen Kanal gesendet werden, bis eine Nachricht empfangen wird, die anzeigt, dass Fensterplatz verfügbar ist.

Port-Weiterleitung

Der Befehl, den Sie haben, sieht gut aus. Sind Sie sicher, dass der Dienst, zu dem Sie eine Verbindung herstellen möchten, aktiv ist und Verbindungen akzeptiert? Die Kanalfehler scheinen darauf hinzudeuten, dass dies nicht der Fall ist.

Was sind meine aktiven Kanäle?

Wenn Sie eine aktive sshVerbindung haben, können Sie die folgende Tastenkombination verwenden, um Hilfe zu erhalten:

Shift+ ~gefolgt von Shift+?

$ ~?
Supported escape sequences:
  ~.  - terminate connection (and any multiplexed sessions)
  ~B  - send a BREAK to the remote system
  ~C  - open a command line
  ~R  - Request rekey (SSH protocol 2 only)
  ~^Z - suspend ssh
  ~#  - list forwarded connections
  ~&  - background ssh (when waiting for connections to terminate)
  ~?  - this message
  ~~  - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
debug2: channel 2: written 480 to efd 8

Sie können dann diese Tastenkombination verwenden, um eine Liste der aktiven Kanäle zu erhalten:

Shift+ ~gefolgt von Shift+#

$ ~#
The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
debug2: channel 2: written 93 to efd 8

Wenn Tomcat Loopback (127.0.0.1) nicht abhört, gibt ein Port, auf den weitergeleitet wird, die Fehlermeldung aus, die Sie erhalten haben.

Wenn ich einen SSH- ssh -L1234:127.0.0.1:9999 10.0.0.1Vorgang durchführe , bei dem ein Port an einen nicht empfangsbereiten Port weitergeleitet wird (z. B .: - Wenn kein Prozess unter 10.0.0.1 an Port 9999 unter 127.0.0.1 gebunden ist), erhalte ich den gleichen Fehler:

channel 2: open failed: administratively prohibited: open failed

Sie können herausfinden, auf welchen Kanal verwiesen wird, indem Sie -vvvIhrer ssh hinzufügen

ssh -vvv -L1570:127.0.0.1:8899 root@thehost

Welchen Port der "andere Prozess" abhört (und auf welchen IP-Adressen), netstat -tulpnwird bestätigen, welche Ports und IPs-Prozesse auf Ihren Servern verwendet werden, das -L muss auf eine Adresse und einen Port verweisen, auf dem er lauscht.