Mimo że coraz więcej projektów wdrażam przez Git i automatyczne procesy, połączenie z serwerem przez FTP lub SFTP wciąż jest codziennym narzędziem: przy szybkiej poprawce, przeniesieniu plików, sprawdzaniu logów czy pracy na hostingu, który nie oferuje nic więcej. W tym wpisie pokazuję, który protokół wybrać, jakie dane są potrzebne, jak skonfigurować połączenie w WinSCP, z którego korzystam na co dzień, oraz jak poradzić sobie z błędami, które pojawiają się najczęściej.
FTP, FTPS czy SFTP
Zanim skonfiguruję połączenie, wybieram protokół. Różnica nie jest kosmetyczna, bo dotyczy tego, czy hasło i pliki przesyłane są otwartym tekstem.
| Protokół | Domyślny port | Szyfrowanie | Kiedy go używam |
|---|---|---|---|
| FTP | 21 | Brak, login i hasło lecą otwartym tekstem | Tylko gdy nie ma innej możliwości, np. w bardzo starych środowiskach |
| FTPS | 21 (jawny) lub 990 (niejawny) | TLS, jak w HTTPS | Gdy hosting nie udostępnia SSH, a obsługuje FTP z szyfrowaniem |
| SFTP | 22 | SSH | Domyślnie wszędzie, gdzie jest dostęp przez SSH |
SFTP mimo podobnej nazwy nie jest wersją FTP, tylko osobnym protokołem działającym w ramach SSH. Ma jedną dodatkową zaletę: korzysta z jednego połączenia, więc nie ma problemów z trybem pasywnym i zaporami, które przy zwykłym FTP są częstą przyczyną zerwanych transferów. Dlatego przy wyborze serwera zawsze sprawdzam, czy hosting daje dostęp przez SSH.
Jakie dane są potrzebne do połączenia
Wszystkie dane znajdziesz w panelu hostingu, zwykle w sekcji FTP lub SSH:
- Host – nazwa serwera lub domena. Jeśli domena nie wskazuje jeszcze na serwer, np. przed przeniesieniem DNS, używam nazwy serwera albo adresu IP podanego przez firmę hostingową.
- Port – zgodny z wybranym protokołem. Niektóre firmy zmieniają port SSH na niestandardowy, warto to sprawdzić w panelu.
- Użytkownik i hasło albo klucz SSH.
- Katalog strony – na wielu hostingach pliki strony znajdują się nie w katalogu głównym konta, tylko np. w
public_htmllub w katalogu nazwanym jak domena. Wgranie plików piętro wyżej to jedna z najczęstszych przyczyn pytania „dlaczego zmiany nie działają”.
Połączenie w WinSCP
Osobiście na co dzień korzystam z WinSCP, po prostu z własnej wygody. Ma czytelny podział na pliki lokalne i zdalne, dobrze obsługuje SFTP i klucze SSH, a dzięki integracji z PuTTY jednym kliknięciem otwieram terminal na tym samym serwerze. Każdy serwer zapisuję jako osobną sesję, żeby przy kolejnym połączeniu nie pomylić protokołu ani katalogu.
- W oknie logowania wybierz Nowa sesja.
- Ustaw protokół SFTP albo, jeśli hosting go nie obsługuje, FTP z szyfrowaniem TLS.
- Wpisz host, port i nazwę użytkownika. Przy logowaniu kluczem wskaż plik klucza w ustawieniach zaawansowanych, w sekcji uwierzytelniania SSH. Klucz w formacie OpenSSH WinSCP sam zaproponuje przekonwertować do swojego formatu.
- W ustawieniach zaawansowanych, w sekcji katalogów, ustaw katalog zdalny, np.
/public_html. - Zapisz sesję i połącz się. Przy pierwszym połączeniu program pokaże odcisk klucza serwera. Akceptuję go dopiero wtedy, gdy zgadza się z danymi od firmy hostingowej.
Dwie rzeczy ustawiam od razu. Pierwsza to hasło główne w ustawieniach programu, które chroni zapisane dane logowania do wszystkich serwerów. Druga to pokazywanie plików ukrytych, bez którego nie zobaczysz na serwerze plików zaczynających się od kropki, w tym pliku .htaccess.
FileZilla i terminal jako alternatywa
Jeśli pracujesz na macOS lub Linuksie albo wolisz program dostępny na wszystkich systemach, dobrym wyborem jest FileZilla. Konfiguracja wygląda podobnie: w Menedżerze stron dodajesz serwer, wybierasz protokół SFTP, wpisujesz dane logowania i domyślny katalog. Tu również warto ustawić hasło główne, bo bez niego zapisane hasła są chronione znacznie słabiej.
W terminalu wystarczą wbudowane polecenia:
sftp uzytkownik@serwer.pl
scp plik.zip uzytkownik@serwer.pl:/public_html/
rsync -avz -e ssh ./build/ uzytkownik@serwer.pl:/public_html/
Przy większej liczbie plików sięgam po rsync, bo przesyła tylko to, co się zmieniło, i można go łatwo uruchamiać w skryptach.
Logowanie kluczem SSH zamiast hasła
Tam, gdzie hosting na to pozwala, loguję się kluczem zamiast hasła. Klucz jest dużo trudniejszy do złamania niż hasło, a dostęp można łatwo odebrać, usuwając klucz z serwera. Klucz generuję raz na komputerze:
ssh-keygen -t ed25519 -C "twoj@email.pl"
Następnie zawartość pliku z kluczem publicznym, kończącego się na .pub, dodaję w panelu hostingu w sekcji kluczy SSH albo
do pliku ~/.ssh/authorized_keys na serwerze. Klucza prywatnego nigdy nie wysyłam ani nie kopiuję na serwer.
Najczęstsze błędy i ich przyczyny
| Komunikat lub objaw | Najczęstsza przyczyna | Co sprawdzam |
|---|---|---|
| Przekroczony czas połączenia | Zły host lub port, blokada na zaporze, SSH wyłączony na koncie | Dane w panelu hostingu, czy dostęp SSH jest aktywny |
| 530 Login incorrect | Błędny login lub hasło, często z pełną nazwą konta FTP w formacie użytkownik@domena | Dokładną nazwę użytkownika z panelu, reset hasła konta FTP |
| Permission denied (publickey) | Klucz publiczny nie został dodany lub program używa innego klucza | Czy klucz jest w panelu lub w authorized_keys, który plik klucza wskazuje program |
| Ostrzeżenie o zmianie klucza serwera | Serwer został przeniesiony lub przeinstalowany, rzadziej próba podszycia | Potwierdzam zmianę u firmy hostingowej, zanim zaakceptuję nowy klucz |
| Listowanie katalogu się zawiesza | Problem z trybem pasywnym przy zwykłym FTP | Przejście na SFTP lub zmiana trybu w ustawieniach połączenia |
| Pliki wgrane, ale zmian nie widać | Zły katalog albo pamięć podręczna | Katalog strony w panelu, wyczyszczenie cache strony i CDN |
| Błąd 403 lub 500 po wgraniu plików | Nieprawidłowe uprawnienia plików | Typowo 644 dla plików i 755 dla katalogów |
Bezpieczna praca na serwerze
- Osobne konto dla każdej osoby lub firmy. Konto FTP ograniczam do katalogu, którego dana osoba potrzebuje, a po zakończeniu współpracy usuwam je zamiast zmieniać hasło.
- Kopia przed zmianą. Zanim nadpiszę plik na działającej stronie, pobieram jego obecną wersję. Edytowanie plików bezpośrednio na produkcji przez klienta FTP to ostateczność.
- Panel hostingu do drobnych rzeczy. Menedżer plików w panelu wystarcza do podejrzenia logu czy podmiany jednego pliku, ale przy większych zmianach jest wolny i łatwo w nim o pomyłkę.
W projektach rozwijanych przez zespół traktuję FTP i SFTP jako narzędzie pomocnicze. Właściwe wdrożenia przechodzą przez repozytorium Git, dzięki czemu każda zmiana ma historię i można ją wycofać, a ręczne przesyłanie plików zostaje na sytuacje awaryjne i jednorazowe zadania, takie jak przeniesienie plików przy migracji strony.