FTP v / s SFTP v / s FTPS


10

Konfigurujemy serwer internetowy w naszym obszarze roboczym. W związku z tym planujemy zainstalować serwer FTP, ale utknąłem przy tym, jakiego protokołu użyć - FTP, SFTP lub FTPS. I googled wokół, starając się zobaczyć, co oferuje protokół co, napotykając artykułów takich jak ten , ale nie mogę się zdecydować. Pożądany jest tylko prosty transfer plików raz na jakiś czas; jednak bezpieczeństwo stanowi problem, ponieważ serwer plików ma być dostępny z Internetu.

Jaki protokół jest najbardziej odpowiedni do mojego użytku i dlaczego?


Czy masz już skonfigurowany Apache z SSL? Następnie dodałbym ... v / s WebDAV :-)
Chris Lercher

Nie, użyjemy lighttpd jako demona HTTP.
susmits,

Jeśli nadal chcesz to rozważyć: WebDAV jest również możliwe dzięki lighttpd howtoforge.com/setting-up-webdav-with-lighttpd-debian-etch
Chris Lercher

Obawiam się, że nie znam WebDAV. Czy możesz podać mi jakieś zalety, jakie ma w porównaniu z innymi programami? A może łączysz mnie z miejscem, które może mi to wyjaśnić?
susmits,

1
Pierwszy argument dla mnie brzmiałby: jeśli mam już serwer HTTP (z SSL), po co konfigurować dodatkowy serwer i dlaczego otwierać dodatkowe porty zapory ogniowej? Więcej argumentów dla WebDAV: howtoforge.com/webdav_with_ssl_and_two_factor_authentication
Chris Lercher

Odpowiedzi:


14

Tak więc dwie rozsądne opcje w dzisiejszych czasach to:

  1. WebDAV, miły po stronie serwera, miły dla klientów Linux i Mac OS, jednak wbudowany klient Windows ma problemy.

  2. SCP / SFTP, bardzo łatwe, ponieważ prawdopodobnie i tak będziesz mieć ssh, klienci GUI są łatwo dostępni (na przykład FileZilla)

Chociaż FTP wciąż istnieje, naprawdę unikałbym tworzenia na jego podstawie niczego nowego.


1
Plus SFTP działa tylko przez jeden port (22). Mniej problemów z zaporami ogniowymi i ich konfiguracją.
JKim,

5

Myślę, że krótką odpowiedzią jest użycie serwera FTP, który obsługuje wszystkie trzy protokoły. Prawdopodobnie chcesz uniknąć FTP, ponieważ wymieniłeś bezpieczeństwo jako główny problem, ale zarówno protokół przesyłania plików SSH2 (SFTP), jak i FTP przez TLS / SSL (FTPS) są uważane za bezpieczne protokoły przesyłania plików.

SFTP jest obecnie zdecydowanie faworytem ze względu na solidny model bezpieczeństwa i łatwiejszą konfigurację niż tradycyjne FTP i FTPS. SFTP jest również znacznie bardziej przyjazny dla zapory ogniowej niż FTP, ponieważ wymaga tylko jednego portu do nawiązania połączenia i wykonania operacji na plikach.

FTP i FTPS wymagają wielu portów (jeden port do wydawania poleceń i osobny port dla każdej listy katalogów lub transferu plików), aby osiągnąć to samo, co SFTP może zrobić z jednym portem. Wymóg skonfigurowania przekazywania dla dużej liczby portów może stanowić problem w wielu środowiskach i bardzo utrudniać rozwiązywanie problemów. Jednak FTP i FTPS są znacznie dłuższe niż SFTP, a wciąż istnieje wiele urządzeń i klientów, które obsługują tylko FTPS.

Pod względem bezpieczeństwa zarówno protokoły SFTP, jak i FTPS są uważane za bezpieczne. Wymóg otwarcia wielu portów za pomocą FTPS może być postrzegany jako problem związany z bezpieczeństwem, ale nie ma nic bardziej bezpiecznego w protokole SFTP nad protokołem FTPS.

Jedyną prawdziwą przewagą, którą dałbym FTPS nad SFTP, była wydajność. SFTP działa na znacznie bardziej niezawodnym i ogólnym protokole niż FTPS, a ta niezawodność ma znaczący wpływ na wydajność. Po prostu SFTP wiąże się z większym obciążeniem, ponieważ działa on na protokole SSH2 i ponieważ SFTP implementuje własny mechanizm uzgadniania. Jeśli chcesz mieć najwyższe możliwe prędkości transferu, potrzebujesz FTPS.

Podsumowując, spróbuj obsłużyć wszystkie 3. Większość współczesnych serwerów FTP obsługuje już FTP, FTPS i SFTP.


2 porty dla (aktywnego) FTP, a niektóre systemy operacyjne mają moduły pomocnicze, które będą obsługiwały drugi automatycznie.
Ignacio Vazquez-Abrams

Myślę, że to zależy od tego, jak na to patrzysz. W przypadku każdego wykazu pojedynczego katalogu lub transferu plików używane są tylko 2 porty (jeden port do połączenia sterującego i jeden port do połączenia danych), ale w praktyce nowy port jest wymagany za każdym razem, gdy następuje nowy transfer danych. Ten nowy port może wymagać otwarcia na serwerze (w trybie pasywnym) lub na kliencie (w trybie aktywnym), ale zwykle nowy port jest nadal wymagany. Oznacza to, że dla dużej liczby transferów na kliencie lub serwerze musi być dostępny szereg portów.
Grant

2

Zdecydowanie unikaj instalowania demona FTP. Tak długo, jak masz SSH, masz SFTP. Nie wymaga dodatkowej konfiguracji. Jedynym powodem do korzystania z FTP są masy.

Pracuję na serwerze FTP, który obsługuje również FTPES (FTP przez jawny SSL) i naprawdę nie widzę żadnych jego zalet, poza tym, że jest już na miejscu. Odziedziczyłem to, a wszystkie konta użytkowników i uprawnienia działają. Ale do wszystkiego innego używam tylko SSH / SFTP.


2

Każdy, kto jest zainteresowany niektórymi liczbami tutaj, to moje wyniki z uruchomienia niektórych testów porównawczych w mojej sieci lokalnej. Wydajność SMB 2.1 wynosi około 112 MB / s

Maszyna: Intel (R) Core (TM) 2 Quad CPU Q8400 @ 2.66GHz / 8GB ram / Gigabit Local Network

FTP Mode                      MB/s CPU Usage/APP   Encrypted
-------------------------------------------------------------
FTP Transfer rate:            120  40.9  proftpd   No
FTPS (SSL) Transfer Rate:      55  99.8% proftpd   Yes
SFTP Transfer Rate:            30  100%  sshd      Yes
Putty SSH Tunnel, (Raw) FTP:   32  100%  sshd      Yes 

0

Zgadzam się z Ryanem. SFTP, jeśli z serwera będzie korzystała tylko ograniczona liczba osób. Jeśli będzie to serwer bardziej otwarty dla publiczności, udostępniłbym tylko FTPES (oba kanały FTP przez jawne SSL) jako jedyny wybór. FTPES jest bezpieczny OBU kanałami (jeśli serwer jest poprawnie skonfigurowany) zarówno pod względem wysyłania nazwy użytkownika FTP, hasła, jak i przesyłanych danych. Nie myśl nawet o FTP. Powiedział Nuff.

Ale jeszcze raz, jeśli to po prostu SFTP, będzie dobrze.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.