Náhrada FTP

[Ruprecht]

Zdravim. Existuje nějaký protokol, který by byl plnohodnotnou náhradou zastaralého FTP? Za plnohodnotnou náhradu nepovažuji SFTP (nadstavba SSH) ani WebDav (nadstavba nad HTTP). U obou těhle řešení je problém s virtálními usery i adresáři, navíc rozchodit to (na rozdíl od FTP) není úplně jednoduché. Navíc se to dělí o číslo portu s nadřazeným protokolem (porty 22 a 80).

Já žádnou plnohodnotnou náhradu (prostě protokol, určený primárně k obousměrnému přenosu souborů v internetu) nenašel. Ale nějak se mi nechce věřit, že by opravdu nic neexistovalo.

[Reklama]

[Filip Jirsák]

U obou těhle řešení je problém s virtálními usery i adresáři

Za prvé to nijak nesouvisí s protokolem, virtuální uživatelé i adresáře jsou věcí implementace. Za druhé to, že vy s tím máte nějaký nespecifikovaný problém, neznamená, že je s tím problém obecně – spousta uživatelů s tím žádné problémy nemá.

navíc rozchodit to (na rozdíl od FTP) není úplně jednoduché

Rozchodit co? SFTP server jsem nerozcházel, funguje mi automaticky jenom tím, že jsem zprovoznil SSH server.

Navíc se to dělí o číslo portu s nadřazeným protokolem (porty 22 a 80).

Použijí se porty, jaké nakonfigurujete.

Já žádnou plnohodnotnou náhradu (prostě protokol, určený primárně k obousměrnému přenosu souborů v internetu) nenašel.

SFTP, HTTP(S), HTTP(S)+WebDAV, rsync, OpenStack Shared File Systems API, OpenStack Object Storage API, různá API  cloudových úložišť (DropBox, OneDrive, Google Drive)...

Nenapsal jste, jaký problém řešíte, takže vám s ním těžko někdo poradí...

[Petr Krčmář]

Správné řešení je zmiňované SFTP. S ničím porty nesdílí, využívá se přímo vlastností SSH, které funguje jako bezpečný šifrovaný kanál pro přenos souborů. Zamknout uživatele v jeho adresáři je triviální, dá se mu zakázat i terminálový přístup, takže se pak nedostane na řádku a nemůže se rozhlížet po serveru.

Funguje to pak úplně stejně jako FTP, ale je to bezpečné, dají se používat přihlašovací klíče a všechny dobré vlastnosti SSH. Používám léta i pro uživatele a nikdy s tím nebyl problém.

[aasdd]

Pridat mod_sftp do Proftpd je urcite vela prace. Config z FTP moze zostat, s nicim sa o nic nedeli.

[Ruprecht]

Petr Krčmář: já mám s SFTP bohužel takovou zkušenost, že je vždy o polovinu pomalejší nez FTP(S) na stejné lince. Někde jsem četl, že je to jednak dáno tím, že SSH je původně protokol pro přenos textových příkazů v reálném čase, nevhodný na přenos velkých dat, a druhak že při návrhu SSH/SFTP byla důležitější bezpečnost než rychlost.

[Reklama]

[Petr Krčmář]

SSH je univerzální protokol pro tvorbu bezpečného tunelu skrz nezabezpečenou síť. Uvnitř tunelu se pak dá otevírat více paralelních sezení pro různé účely a další protokoly. Neplatí tedy rozšířený omyl, že se terminálové sezení zneužívá k jinému účelu - přenosu souborů.

Pomalejší je to prostě proto, že FTP je opravdu triviální protokol, kdežto SSH přidává režii navíc a hlavně šifrování, které zatěžuje obě strany. To se projeví nejen u SSH, ale libovolného šifrování. Když to FTP budete tunelovat v OpenVPN, taky se to významně odrazí na výkonu.

[Ruprecht]

Petf Krčmář: šifrování beru, ovšem dnešní procesory zvládnou šifrovat nějaký 100 Mbps datový tok s prstem v nose. Proč nepociťuji rozdíl v rychlosti při stahování přes HTTP a HTTPS, ale vidím rozdíl v rychlosti mezi FTP a FTPS?

[.]

Petf Krčmář: šifrování beru, ovšem dnešní procesory zvládnou šifrovat nějaký 100 Mbps datový tok s prstem v nose. Proč nepociťuji rozdíl v rychlosti při stahování přes HTTP a HTTPS, ale vidím rozdíl v rychlosti mezi FTP a FTPS?

Možná by bylo dobré si ujasnit rozdíl mezi SFTP a FTPS.

[Tomas2]

sftp je opravdu často pomalejší, může za to podpora jeho shellu a nutnost parsovat a ošetřovat příkazy. Pokud je možné, scp je na přenos souborů mnooohem efektivnější, také je uzavřené v ssh, je možné ho i nakonfigurovat, aby bylo plně kompatibilní s chrootu u mod_sftp, ale s tím je poměrně dost opičáren s binárkami nebo kompilací.

sftp je ale při přenosu velkého množství malých souborů mnohonásobně efektivnější než ftp. Pokud jde o rychlost přenosu velkého souboru, není špatná volba třeba běžně dostupný rsync (opět nad ssh), umí poměrně hezky komprimovat, přenášet ve více kanálech a pokračovat v nedokončeném přenosu.

[ES]

Rychlost se da vyrazne optimalizovat nastavenim "ciphers" a "macs" v configu sshd
pripadne  pouzit
https://www.psc.edu/hpn-ssh

[aaa]

sftp je opravdu často pomalejší, může za to podpora jeho shellu a nutnost parsovat a ošetřovat příkazy

S tymto som sa este nestretol. Prikazy musi parsovat aj FTP a tie su dokonca textove a teda dlhsie.

U SFTP je to binarna sprava, ktora zacina 1 byte tagom oznacujucim typ spravy. To sa da velmi efektivne parsovat.
Mozes to rozviest?

[Sten]

sftp je opravdu často pomalejší, může za to podpora jeho shellu a nutnost parsovat a ošetřovat příkazy.

SFTP nic takového nedělá, používá vlastní kanál a binární protokol, žádný shell tam neběží. Nepletete si to s FISH (Files transferred over Shell protocol)? To se ale tak patnáct let nepoužívá. I tak je takové parsování řádově rychlejší než samotné šifrování.

Pokud je možné, scp je na přenos souborů mnooohem efektivnější, také je uzavřené v ssh, je možné ho i nakonfigurovat, aby bylo plně kompatibilní s chrootu u mod_sftp, ale s tím je poměrně dost opičáren s binárkami nebo kompilací.

V čem je to efektivnější, když používáte SCP pomocí SFTP?