SSH en FTP

[ZaZ]

Inleiding:

Ik heb een probleem waar ik mijn hoofd niet om kan vouwen.
Ik weet dat er vele oplossingen bestaan en in zoverre is het ook niet echt een probleem, maar ik wil begrijpen waarom dit niet werkt.
Ik ben totaal geen expert op netwerk gebied, dus....

Probleemomschrijving:

Ik heb 2 netwerken: Voor het gemak 192.168.1.x en 192.168.2.x
Ik wil dat alle computers in netwerk1 op een FTP kunnen komen dmv een soort van proxy in netwerk1 op een server in netwerk 2.
In netwerk2 heb ik de FTP ingesteld dat de datapoorten een beperkte range hebben.
In netwerk2 draait een SSH server.
In netwerk1 connect een SSH client op de SSH server in netwerk2 en doet aan portmapping voor poort 21 en 5 ingestelde dataports naar local 0.0.0.0 (zodat andere binnen dat netwerk erop kunnen connecten)
De remote ports wijzen naar de FTP server binnen netwerk2 (dat is niet de SSH server)
De computer waarop de SSH client draait kan zelf op deze manier connectie maken door te ftp'en naar localhost en daarna een PASV commando te sturen.

Als een andere computer in netwerk1 connect naar de SSH client in netwerk1 dan is de ftp verbinding maken geen probleem. Probleem komt na het roepen van het PASV commando.
De ftp server geeft de datapoort terug met ip 192.168.2.x
Nu begrijp ik wel dat die computer daarop niet kan connecten, maar waarom lukt het de SSH client dan wel?
Voor die computer (in netwerk1 dus) is het x.x.2.x netwerk toch ook helemaal niet bekend?

Is er een manier om dit probleem middels SSH normaal op te lossen?

[RaZ]

Met PASV maak je een connectie van IP1 naar IP2, maar die kunnen elkaar helemaal niet zien, want het zijn gescheide netwerken.

Met PASV bypass je dus de proxy server. Je moet dus active mode gebruiken (en de proxy server gebruiken).

Het probleem staat dus los van SSH.

Beste oplossing is op de FTP-server op beide netwerken hebben, dan heb je daar geen proxy voor nodig.

[ZaZ]

Nee met PASV stuurt de server een poort (en volgens mij ook ip) terug waarop de server luistert.
Met ACTIVE mode maakt de server een connectie op de poort die de client stuurt.
Na het PASV command stuurt de server (192.168.2.x,x,x)
Maar dan vind ik het wel vreemd dat de SSH client in netwerk1 wel de datapoorten kan openen, want die kan immers niet naar 192.168.x connecten?
Toch gaat het kennelijk wel goed, maar dan snap ik niet waarom een willekeurige workstation in netwerk1 daar dan weer moeite mee heeft.

Ik doe dit om iets meer van SSH te leren en ben benieuwd of het mogeljik is dit probleem te tacklen middels SSH.
Bij de files op de ftp komen is via een andere weg geen probleem, dus ben ook niet echt opzoek naar een andere oplossing.

[Lieter]

Als ik jou was zou ik, als je al SSH gebruikt, gebruik maken van sftp. In de opensshd zit dit naar mijn weten standaard ingebakken. Dit houdt in dat een datakanaal wordt ge-opend binnen je SSH sessie voor het verzenden van bestanden.

ftp is m.i. een inherent onveilig protocol. En op deze manier hoef je niet te klooien met een command port en een data connectie (al dan niet pasv).

[hiekikowan]

^ Met Lieter...

Waarom zou je nog gebruik maken van FTP als je daarvoor extra paketten nodig hebt... SFTP zit standaard in openssh en werkt net zo snel en veiliger. Het enige verschil wat je als gebruiker merkt is het feit dat je over poort 22 inplaats van 21 moet connecten.

[ZaZ]

Maar ik ben niet opzoek naar een alternatief, dat is niet de reden van mijn vraag.
Ik heb ook gewoon een VPN verbinding die kant op, dus ik heb geen echt probleem.

[hiekikowan]

Dan denk ik dat je inderdaad met een probleem zit.

Het is mij nog niet geheel duidelijk...

- Heb je een verbinding tussen de twee netwerken?
- Als je een verbinding hebt, waarom connect je dan niet rechtstreeks met de FTP-server?

Als je geen verbinding hebt tussen de servers kan je volgens mij nooit connecten.

[ZaZ]

De enige verbinding in deze testcase is poort 22 naar de SSH server in netwerk2, wat een andere computer is dan de ftp server in netwerk2
Vanaf netwerk1 kan ik met de SSH client dmv portforwarding een connectie met de FTP maken en ook de datapoorten forwarden gaan dan goed.
Op deze manier kan ik dus gewoon ftp'en door naar localhost te connecten.
Die SSH client kan natuurlijk ook gewoon runnen op elke andere workstation in netwerk1 en dan zal het ook allemaal wel werken.
Wat ik nu aan het testen ben is om de SSH client op alle interfaces te laten luisteren zodat de andere workstations in netwerk1 kunnen connecten naar
ftp://sshclientInNetwerk1

Dat gaat tot op zekere hoogte goed, maar connectie met de datapoorten vormt nog een probleem.
Ik probeer dus een beetje duidelijk te krijgen wat er nu allemaal gaande is en waarom het niet werkt.

[Kees]

Kies je uit zelfkastijding voor het FTP protocol of er is een serieus bijzonder goede reden voor (die ik niet zou kunnen bedenken). Je kan ook gewoon met SFTP werken, dat is ssh based, en geen gedoe met verschillende datalijnen.

[ZaZ]

Wat ik al een paar keer uit heb proberen te leggen is dat ik gewoon vertrouwd wil raken met hoe krachtig je SSH zou kunnen toepassen. Dat er nou toevallig een ftp server draait en ik die heb gekozen is bijzaak. Zou net zo goed elke andere service kunnen zijn.
Ftp kom ik nogal eens tegen ergens en dan wil ik er makkelijk bij kunnen komen voor eenmalige taken, dus er is wel enige toepasbaarheid, alleen niet perse in dit scenario.

[igmar]

ZaZ schreef op woensdag 14 december 2011 @ 01:58:
Inleiding:
Als een andere computer in netwerk1 connect naar de SSH client in netwerk1 dan is de ftp verbinding maken geen probleem. Probleem komt na het roepen van het PASV commando.
De ftp server geeft de datapoort terug met ip 192.168.2.x
Nu begrijp ik wel dat die computer daarop niet kan connecten, maar waarom lukt het de SSH client dan wel?
Voor die computer (in netwerk1 dus) is het x.x.2.x netwerk toch ook helemaal niet bekend?

Nee, en daarom moet het device wat NAT doet ook die IP's en poortnummer rewriten. Onder Linux wordt dat gedaan in de kernel (ip_conntrack_ftp en ip_nat_ftp).

Je SSH client heeft geen apart datakanaal (wat FTP wel heeft), en heeft dus dat probleem niet. De oplossing : Een proxy tussen de 2 netwerken, of anders NAT onder Linux gebruiken.