Das kann ja kaum alles sein ... einfach mal angenommen, auf dem "linken" PC wird jetzt ein SSH-Tunnel zur FRITZ!Box (dem "rechten" PC) aufgebaut und der dortige Port 1234 wird auf den linken PC auf Port 5678 getunnelt (also -R 1234:localhost:5678), dann hat davon ja noch kein PC hinter der FRITZ!Box irgendetwas.
Wenn auf dem linken PC (als SSH-Client) eine Verbindung zu einem SSH-Server gestartet wird und die endet bei "localhost:3389" auf dem linken PC (was ja dann MS-RDP auf diesem PC wäre), was bringt denn dann ein Port 3389 auf der FRITZ!Box, wenn der nicht auch noch "von außerhalb" der Box benutzbar ist? Das ist dann genau der Unterschied, den man (beim OpenSSH) mit "GatewayPorts <no|yes|clientspecific>" konfigurieren kann, denn normalerweise bindet der Server solche Ports nur an "localhost" und die lokalen Adressen (127.0.0.1 und ::1). Beim "dropbear" gibt es dann für "yes" die Option "-a" (hat
@Whoopie Dir ja schon mitgeteilt) und ohne die wird kein Client aus dem FRITZ!Box-LAN auf den Tunnel zugreifen können ... selbst wenn der noch so schön aufgebaut wurde.
Du wirst also wohl mit etwas wie "ssh -R 3389:localhost:3389 mybox.myfritz.net" vom linken PC eine SSH-Verbindung zur FRITZ!Box aufbauen wollen (die dazu natürlich auch auf Port 443 mit dem SSH-Server Verbindungen entgegennehmen muß, wenn "hosta" nur diesen Port als Ziel ansprechen darf) ... warum kannst Du das nicht einfach mal selbst so aufschreiben?
Dazu gehört dann eben auch das jeweilige Fehlerprotokoll ... es ist schon ein gewaltiger Unterschied, ob bereits beim SSH-Aufruf auf "hosta" irgendetwas mit "rejected" kommt oder erst beim Zugriffsversuch auf den weitergeleiteten Port an der FRITZ!Box mit "remote desktop connection". Der "dropbear" erzeugt auch genauere Fehlernachrichten, wenn man ihn mit "DEBUG_TRACE"-Option übersetzt und mit "-v" aufruft.
Ist das wirklich soo schwer zu verstehen, was damit gemeint ist, wenn Du
genaue Informationen weiter- und wiedergeben sollst?
Jedenfalls hat der "dropbear" an der Stelle tatsächlich ein paar Einschränkungen (er unterstützt z.B. die Angabe von 0 als Portnummer (für "Server sucht aus") nicht), aber die Angabe von "address to bind" aus dem RFC wertet er tatsächlich aus, solange auch noch "-a" beim Aufruf des Servers angegeben wurde (ansonsten wird das auf "localhost" als Angabe im Request zurückgesetzt).
Aber wie gesagt ... theoretisch (dem Quelltext nach) sollte es mit "dropbear" funktionieren und woran es bei Dir nun genau klemmt, kannst Du nur selbst ermitteln und dazu gehören (a) so viele Protokoll-Ausgaben wie möglich (eben u.a. auch erst einmal ein "dropbearmulti"-Binary, welches mit Trace-Support übersetzt wurde) und (b) das Überprüfen jedes Teilschritts.
Nach dem Start hat so ein SSH-Server dann eben lokal nur einen Listener auf Port 443 (oder wie Du das auch immer in der AVM-Firewall lösen magst, auch dazu fehlt ja jede Angabe) und spätestens mit der ersten Verbindung mit "remote port forwarding" muß dann auf dem richtigen Interface und dem richtigen Port auch noch ein passender Listener dazukommen. Wenn das nicht stattfindet, sind ja schon die Grundlagen falsch umgesetzt und man braucht gar nicht erst versuchen, auf den (ohnehin geschlossenen) Port irgendwie zuzugreifen. Am Ende geht hier aus dem Thread nicht einmal klar hervor, ob die Verbindung
für den Tunnel überhaupt aufgebaut werden kann. Notfalls muß man sogar zum Paketmitschnitt greifen, um überhaupt erst einmal festzustellen, ob ein Paket von "hosta" und dem dort gestarteten SSH-Client überhaupt bei der Box (und als nächstes dann auf deren lokalem Interface) ankommt.
