Najlepiej przekieruj z WAN do LAN usługę ssh na innym porcie po stronie WAN, niż ma dropber w tym routerze - tak jest najprościej i najpewniej.
Wtedy wołasz ze zdalnego hosta np. (jak to jakaś powłoka linuxa):
ssh xxx@yyy.zz -p XXXX
i zawsze Cię wtedy przekieruje na serwer ssh na danym urządzeniu LAN, gdzie urządzenie może słuchać np. na domyślnym porcie 22 (czy jakimkolwiek innym - nikt nie mówi, że musi to być 22 - wszystko zależy od tego jak to sobie ustawisz - nawet bezpieczniej jest używać innego portu - w routerze też zresztą warto przestawić domyślny port na inny).
Krótko mówiąc izolujesz usługę ssh dla routera od tej w urządzeniach LAN - i tak jest najbezpieczniej.
Generalnie to zły pomysł mieć otwarty ssh na routerze od strony WAN, jak jest już niepotrzebny - unikać takiej sytuacji jak to tylko możliwe.

Otwórz na firewallu. Dropbear tego nie zrobi samodzielnie.

Nic nie zrobiło. To co pokazałeś to tylko oznacza że słucha na danym interfejsie (lub wszystkich). Nie oznacza to ze magicznie na firewallu też jest do niego dostęp.

Jeszcze raz dla wyjaśnienia wszystkich wątpliwości, chciałem przedstawić rysunek.
Ponieważ nie mam uprawnień do konfiguracji firewalla w lokalizacji, gdzie stoi komputer z aplikacją, do której chcę się podłączyć, niemożliwe jest proste połączenie (linia czerwona). W związku z tym otwieram zdalny port na swoim domowym routerze, który jest przekazywany do portu na komputerze za firewallem. Robię to za pomocą putty na tymże komputerze za firewallem, wykorzystując remote port forwarding (linia niebieska). W teorii powinno to umożliwić połączenie z laptopa poprzez tak zestawione połaczenie (linia zielona). Niestety, pomimo że port na routerze otwiera się, nasłuchuje jedynie na adresie 127.0.0.1, a zatem nie mogę podłączyć się do tego portu z mojej podsieci domowej. Czy ktoś miałby jakieś sugestie, dlaczego pomimo włączonej opcji GatewayPorts na routerze, nie mogę uzyskać tego połączenia?

Nie chodzi o obejście firewalla (który akurat jest zupełnie osobnym urządzeniem), bo jak najbardziej mogę się dostać do tej sieci poprzez VPN, ale jest to niewygodne z różnych względów, np. rozłączanie raz dziennie, przekierowanie całego ruchu sieciowego przez VPN etc. etc. Poza tym, przecież piszę, że potrafię to zrobić, ponieważ tunel się otwiera, i nawet potrafię się podłączyć tworząc drugi tunel z laptopa do mojego routera (o czym nie pisałem, żeby nie zaciemniać obrazu), ale chcę to uprościć.
Zadałem więc pytanie techniczne, związane z konfiguracją dropbear'a, licząc że ktoś kto ma wiedzę, spróbuje pomóc (jak Cezary i build0000), a jak ktoś nie wie to nie będzie bił piany

@build000: o i to jest już odpowiedź na moje pytanie, choć może pośrednia. Szkoda tylko, że nie napisałeś wcześniej, że takie ograniczenie istnieje, zaoszczędziłbym trochę czasu na eksperymenty. Jak już pisałem, mogę to zrobić inaczej, choć mniej wygodnie, więc przy tym pozostanę. A posądzanie mnie o włamanie to jest trochę nadinterpretacja (szczególnie w świetle posta nr 10), ale to chyba dosyć popularne, że szuka się u kogoś najgorszych intencji, prawda?

Hej,

Własnie walczyłem z tym samym problemem.

Wygląda na to, że w tutorialu Cezarego jest błąd: http://eko.one.pl/?p=openwrt-sshtunnel
Prawidłowa opcja do odblokowania forwardowania portów w pliku /etc/config/dropbear to:

        option GatewayPorts 'on'

możesz to zweryfikować patrząc na procesy:

 ps | grep drop
 3083 root      1232 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a

jeśli parametr -a jest obecny to opcja jest aktywna
(-a              Allow connections to forwarded ports from any host)

Dodatkowo demon dropbear działa trochę inaczej niż inne unixowe sshd i domyślnie nasłuchuje tylko na 127.0.0.1.

Żeby to zmienić musisz przy tworzeniu reverse tunelu od strony klienta wskazać konkretny interfejs na serwerze.

Czyli zamiast:

ssh -f -NT -R 4445:localhost:22 192.168.1.2

Wywołujesz:

ssh -f -NT -R 192.168.1.2:4445:localhost:22 192.168.1.2 

lub bardziej ogólnie:

ssh -f -NT -R 0.0.0.0:4445:localhost:22 192.168.1.2 

(wtedy serwer słuch na wszystkich interfejsach - czyli działa tak jak inne demony sshd).

Pzdr
Krzych

Zobacz:

root@Gargoyle:~# uci set dropbear.global.GatewayPorts=yes
root@Gargoyle:~# uci commit dropbear
root@Gargoyle:~# /etc/init.d/dropbear restart
root@Gargoyle:~# ps | grep drop
 3382 root      1256 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4014 root      1164 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22
 4016 root      1496 S    grep drop
root@Gargoyle:~#
root@Gargoyle:~# uci set dropbear.global.GatewayPorts=on
root@Gargoyle:~# uci commit dropbear
root@Gargoyle:~# /etc/init.d/dropbear restart
root@Gargoyle:~# ps | grep drop
 3382 root      1256 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4035 root      1164 S    /usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 -a
 4037 root      1496 S    grep drop

Proces 3382 to bieżaca sesja ssh więc nie jest restartowana.

Pzdr
Krzych

Ha, W AA działało, a teraz inaczej są weryfikowane parametry ...

Ja tam nie wiem, swieżonka jestem w Gargoylu ;-)

Btw, szkoda, że w twoich tutorialach nie można dodawać komentarzy. Byłoby łatwiej wyłapywać takie rzeczy.

Pzdr
Krzych

To dziwne. U mnie słucha wyłącznie na podanym interfejsie.

Na kliencie wywołuję:

root@Gargoyle:~# ssh -f -NT -R 192.168.1.22:4445:localhost:22 192.168.1.2

A na serwerze mam dwa interfejsy:
192.168.1.2 i 192.168.1.22 (secondary IP na LANie):

root@gargoyle2:~# netstat -taupen | grep 4445
tcp        0      0 192.168.1.22:4445       0.0.0.0:*               LISTEN      2622/dropbear
root@gargoyle2:~#
root@gargoyle2:~# telnet 127.0.0.1 4445
telnet: can't connect to remote host (127.0.0.1): Connection refused
root@gargoyle2:~#
root@gargoyle2:~# telnet 192.168.1.2 4445
telnet: can't connect to remote host (192.168.1.2): Connection refused
root@gargoyle2:~#
root@gargoyle2:~# telnet 192.168.1.22 4445
SSH-2.0-dropbear_2014.65

jak widać nawet na localhoscie nie słucha.

Pzdr
Krzych

I to jest właśnie powód by nie robić takich zajawek w openwrt/gargoyle. Gdy jeszcze bardziej to rozkminisz dojdziesz do wniosku, że więcej złego niż dobrego dają takie manewry i w efekcie końcowym jesteś jak otwarta księga dla każdego bardziej dociekliwego jegomościa w internecie.