Do czego odnoszą się numery kanałów w komunikacie o błędzie ssh?

W poniższym przykładzie odpowiadają numerom kanałów? Które są na serwerze? Które są na kliencie?

  $ 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

Klient ssh działa w systemie Windows 7, a serwer ma serwer Tomcat działający na porcie 8899.

Tomcat nie nasłuchuje na 127.0.0.1 na zdalnej maszynie, więc jeśli zmienię polecenie na ssh -L1570:thehostpublicip:8899 root@thehostprzekierowanie portów, działa. Wiem więc, że przekierowanie portów wydaje się działać dobrze na serwerze.

mój plik konfiguracyjny sshd zawiera następujące dwa wiersze:

# 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

Próbuję skonfigurować przekierowanie portów dla innego procesu niż Tomcat i otrzymuję komunikaty o błędach podobne do powyższych, więc próbuję zrozumieć znaczenie komunikatów o błędach.

Z dokumentacji protokołu SSH dotyczącej kanałów:

Wszystkie sesje terminali, przekierowane połączenia itp. Są kanałami. Każda ze stron może otworzyć kanał. Wiele kanałów jest multipleksowanych w jedno połączenie.

Kanały są oznaczone numerami na każdym końcu. Liczba odnosząca się do kanału może być różna z każdej strony. Żądania otwarcia kanału zawierają numer kanału nadawcy. Wszelkie inne wiadomości związane z kanałem zawierają numer kanału odbiorcy dla kanału.

Kanały są sterowane przepływem. Żadne dane nie mogą być wysyłane do kanału, dopóki nie zostanie odebrany komunikat wskazujący, że przestrzeń okna jest dostępna.

Przekierowanie portów

Polecenie, które masz, wygląda dobrze. Czy na pewno usługa, z którą próbujesz się połączyć, działa i akceptuje połączenia? Błędy kanału wydają się wskazywać, że tak nie jest.

Jakie są moje aktywne kanały?

Jeśli masz aktywne sshpołączenie, możesz użyć następującej kombinacji klawiszy, aby uzyskać pomoc:

Shift+ ~następnie 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

Następnie możesz użyć tej kombinacji klawiszy, aby uzyskać listę aktywnych kanałów:

Shift+ ~następnie 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

Jeśli tomcat nie nasłuchuje w trybie sprzężenia zwrotnego (127.0.0.1), wówczas port przekierowany do tego spowoduje wyświetlenie komunikatu o błędzie.

Jeśli wykonam ssh, z portem przekierowanym do portu nie nasłuchującego (np .: ssh -L1234:127.0.0.1:9999 10.0.0.1- gdy żaden proces na 10.0.0.1 nie jest powiązany z portem 9999 na 127.0.0.1), pojawia się ten sam błąd:

channel 2: open failed: administratively prohibited: open failed

Możesz dowiedzieć się, o którym kanale mowa, dodając -vvvdo swojego ssh

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

Na jakim porcie nasłuchuje „inny proces” (i na jakich adresach IP) netstat -tulpnpotwierdzi, z jakich portów i procesów IP korzystają na twoich serwerach, -L będzie musiał wskazać adres i port, na którym nasłuchuje.