SFTP zamiast FTP w WordPress: przejdź na klucze SSH

Wystarczy otworzyć w panelu hostingowym listę kont FTP. Na wielu stronach WordPress znajdzie się co najmniej jedno logowanie, którego nikt nie potrafi wyjaśnić. Może pochodzić od agencji, która budowała stronę, od freelancera, który trzy lata temu naprawiał wtyczkę, albo być testowym kontem o nazwie ftp1. Odpowiedź w kwestii SFTP zamiast FTP jest prosta: usunąć te konta, przestać używać zwykłego FTP i dać każdej osobie własny klucz SSH do SFTP. Ten poradnik opisuje tę zmianę w kolejności, która nikogo nie wyklucza z dostępu.

SFTP zamiast FTP: dlaczego zwykły FTP trzeba porzucić

Zwykły FTP wysyła nazwę użytkownika, hasło i każdy plik bez szyfrowania. Każdy, kto znajduje się na trasie połączenia, może to wszystko odczytać: w hotelowym Wi-Fi, przez przejęty router w biurze albo u niedbałego dostawcy sieci. Dotyczy to także pliku wp-config.php z hasłem do bazy danych, jeśli kiedykolwiek pobierano go przez FTP.

Logowania FTP działają też całkowicie poza WordPressem. Uwierzytelnianie dwuskładnikowe w wp-admin ich nie chroni, a konta te nie pojawiają się na liście użytkowników WordPressa. Osoba z działającym hasłem FTP może wgrać plik PHP i uruchomić kod na stronie, nie widząc nawet ekranu logowania.

Zmiana protokołu ma wyraźne granice. SFTP nie pomoże, jeśli zainfekowany jest laptop z kluczem, i nic nie zrobi z podatną wtyczką. Zamyka jedne konkretne drzwi: czytelne dane logowania i zapomniane konta z dostępem do systemu plików.

FTP, FTPS i SFTP w porównaniu

Nazwy łatwo pomylić, więc w skrócie:

FTPS to stary protokół FTP owinięty w TLS. Szyfruje ruch, ale nadal otwiera osobne połączenia danych. Te często kolidują z zaporami sieciowymi i NAT, czego skutkiem jest klasyczny błąd „directory listing failed". SFTP, mimo nazwy, nie ma z FTP nic wspólnego. Jest podsystemem SSH, działa przez jedno szyfrowane połączenie i pozwala logować się kluczami SSH zamiast hasłem.

Nasza rekomendacja: SFTP, jeśli hosting oferuje dostęp przez SSH. FTPS tylko jako rozwiązanie awaryjne. Zwykłego FTP nie używać wcale. W FileZilli protokół ustawia się w Menedżerze witryn (Site Manager): „SFTP - SSH File Transfer Protocol". Jeśli trzeba użyć FTPS, należy wybrać „Require explicit FTP over TLS". Nie wybierać opcji „Use explicit FTP over TLS if available", bo gdy TLS zawiedzie, po cichu wraca ona do zwykłego FTP. WinSCP ma ten sam wybór w polu „File protocol".

Stare konta FTP: najpierw inwentaryzacja i usunięcie

Zanim powstanie jakikolwiek klucz, trzeba zrobić spis kont. Gdzie szukać:

• W sekcji kont FTP w panelu hostingowym (cPanel, Plesk i podobne panele mają taką sekcję).
• W sekcji dostępu SSH lub kluczy SSH, razem z kluczami, które są już autoryzowane.
• Na własnym serwerze: użytkownicy systemowi z powłoką logowania (grep -vE 'nologin|false' /etc/passwd) oraz każdy plik ~/.ssh/authorized_keys.

Przy każdym koncie warto zapisać, kto z niego korzysta i do czego. Jeśli nikt nie umie wskazać właściciela, konto należy usunąć. Zmiana hasła nie wystarczy. Jeśli hasło do głównego konta hostingowego zostało kiedykolwiek wpisane w kliencie FTP, trzeba zmienić także je. Przynajmniej raz przeszło ono przez sieć bez szyfrowania.

Dobrze zachować krótką notatkę z porządków: data, usunięte konta, kto to zatwierdził. Równolegle warto przejrzeć w ten sam sposób logowania do samego WordPressa. Tę stronę omawia nasz poradnik o bezpieczeństwie ról użytkowników WordPress.

Klucz SSH z hasłem (passphrase): jeden na osobę

Każda osoba tworzy własny klucz na własnym komputerze. macOS, Linux i aktualne wersje Windows mają wbudowany OpenSSH:

ssh-keygen -t ed25519 -C "anna@example-company.eu"

Wystarczy zaakceptować domyślną lokalizację, a po prośbie programu ustawić hasło do klucza (passphrase). Nie wolno go pomijać. Polecenie tworzy dwa pliki:

• ~/.ssh/id_ed25519 to klucz prywatny. Nigdy nie opuszcza urządzenia.
• ~/.ssh/id_ed25519.pub to klucz publiczny. Ten właśnie się przekazuje.

Żeby nie wpisywać hasła przy każdym połączeniu, można raz na sesję załadować klucz do agenta poleceniem ssh-add ~/.ssh/id_ed25519. W Windows trzeba najpierw włączyć usługę „OpenSSH Authentication Agent". Niektóre programy, na przykład PuTTY, wymagają formatu .ppk. PuTTYgen potrafi zaimportować klucz OpenSSH i zapisać kopię .ppk. Wszystkie opcje wymienia podręcznik ssh-keygen.

Dlaczego jeden klucz na osobę? Odebranie komuś dostępu sprowadza się wtedy do usunięcia jednej linii, a logi pokazują, czyim kluczem się logowano. Współdzielone klucze i konta uniemożliwiają jedno i drugie, dlatego przy tej migracji warto je wycofać.

Dodanie klucza publicznego: panel hostingowy lub ~/.ssh/authorized_keys

Na hostingu zarządzanym lub współdzielonym wystarczy otworzyć sekcję dostępu SSH lub kluczy SSH. Wkleić klucz publiczny, nadać mu rozpoznawalną nazwę i, jeśli panel tego wymaga, autoryzować go (cPanel ma osobny krok „Authorize").

Na własnym serwerze klucz dopisuje się do pliku authorized_keys użytkownika i ustawia restrykcyjne uprawnienia:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat anna.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Jeśli logowanie hasłem nadal działa, to samo zrobi ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host, uruchomione z komputera danej osoby. Komentarz na końcu każdej linii klucza (anna@example-company.eu) warto zachować. Dzięki niemu za dwa lata będzie wiadomo, do kogo klucz należy.

Test logowania kluczem, potem wyłączenie logowania hasłem

Bieżącą sesję lub kartę panelu warto zostawić otwartą. W drugim terminalu testuje się nowy klucz:

ssh -i ~/.ssh/id_ed25519 user@host

Można też połączyć się klientem SFTP, wskazując plik klucza. Dopiero gdy działa to u każdej osoby, która potrzebuje dostępu, wolno wyłączyć uwierzytelnianie hasłem. W panelu hostingowym jest to zwykle przełącznik w sekcji SSH. Jeśli na hostingu współdzielonym go nie ma, trzeba zapytać dostawcę, czy dla konta można wyłączyć logowanie hasłem przez SSH i FTP.

Na własnym serwerze ustawia się to w /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

Należy też sprawdzić pliki w /etc/ssh/sshd_config.d/. Niektóre obrazy chmurowe zawierają dodatkowy plik z ustawieniem PasswordAuthentication yes. Przed przeładowaniem trzeba zweryfikować konfigurację i potwierdzić wartość faktycznie obowiązującą:

sudo sshd -t
sudo sshd -T | grep -i passwordauthentication
sudo systemctl reload ssh

W systemach opartych na Red Hat usługa nazywa się sshd.

Od tej chwili procedura odejścia osoby z zespołu obejmuje jeden dodatkowy krok: w dniu jej odejścia usuwa się linię z jej kluczem.

FS_METHOD i dane FTP w wp-config.php

Czasem WordPress przy instalacji lub aktualizacji wtyczki wyświetla formularz „Informacje o połączeniu". Dzieje się tak, bo PHP nie może zapisywać plików bezpośrednio, co zwykle wynika z błędnego właściciela plików. Przyczynę wyjaśnia nasz artykuł o uprawnieniach plików w WordPress.

Częstym obejściem było wpisanie danych FTP do wp-config.php:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_HOST', 'ftp.example.de' );
define( 'FTP_USER', 'webuser' );
define( 'FTP_PASS', 'the-hosting-password' );

Aktualizacje wtedy działają, ale hasło do hostingu leży jawnym tekstem w pliku, który PHP czyta przy każdym żądaniu. Jeśli wp-config.php wycieknie, na przykład przez kopię zapasową, źle skonfigurowany serwer lub podatną wtyczkę, razem z nim wycieknie dostęp do plików. Obecność tych stałych sprawdza się tak:

grep -nE "FS_METHOD|FTP_(HOST|USER|PASS|SSL|PUBKEY|PRIKEY)" wp-config.php

To samo sprawdzenie trzeba wykonać w katalogu wyżej, bo niektóre instalacje trzymają wp-config.php poziom wyżej. Stałe należy usunąć i poprawić właściciela plików tak, by WordPress mógł zapisywać je bezpośrednio. Wtedy działa FS_METHOD ustawione na 'direct', a można go też w ogóle pominąć. Wartości 'ssh2' używa się tylko tam, gdzie rozszerzenie PHP ssh2 i dedykowany klucz są poprawnie skonfigurowane. Potem trzeba usunąć konto FTP, do którego odwoływała się konfiguracja, albo przynajmniej zmienić jego hasło. Wszystkie te stałe opisuje dokumentacja wp-config.php w WordPress. Pozostałe ustawienia tego pliku omawia nasza lista kontrolna utwardzania wp-config.php.

Darmowa wtyczka Security Audit & Compliance z secaudit.eu skanuje stronę pod kątem ujawnionych sekretów i plików oraz problemów z utwardzaniem, co pomaga wychwycić dane logowania zostawione w niewłaściwym miejscu. Nie widzi jednak listy kont FTP w panelu hostingowym, więc inwentaryzacja opisana wyżej pozostaje zadaniem ręcznym.

FAQ

Czy FTPS wystarczy, jeśli hosting nie oferuje SSH?

Jako rozwiązanie awaryjne jest akceptowalny, bo ruch jest szyfrowany. Klienta trzeba ustawić tak, by wymagał TLS, dla każdej osoby użyć silnego, unikalnego hasła i mimo to usunąć stare konta. Jeśli hosting w ogóle nie daje dostępu SSH i nie potrafi powiedzieć, kiedy to zmieni, warto rozważyć przeniesienie strony do innego dostawcy.

Czy do SFTP potrzebne są klucze SSH, czy wystarczy hasło?

SFTP z hasłem jest już znacznie lepsze niż FTP, bo hasło przesyłane jest szyfrowanym kanałem. Klucze są jednak lepsze. Nie da się ich odgadnąć ani wyłudzić na fałszywej stronie logowania, ponieważ klucz prywatny nie opuszcza urządzenia. Użycie jednego klucza publicznego na kilku serwerach nie naraża go tak, jak ponowne użycie hasła, a każdy klucz można usunąć osobno.

Co zrobić, gdy ktoś zgubi laptop z kluczem?

Klucz publiczny tej osoby trzeba usunąć z każdego serwera i panelu jeszcze tego samego dnia. Hasło do klucza daje trochę czasu, ale nie jest powodem do zwłoki. Osoba generuje potem nową parę kluczy na nowym urządzeniu.

Czy zwykły FTP to problem z punktu widzenia RODO?

RODO w art. 32 ust. 1 lit. a wymienia szyfrowanie jako przykład odpowiedniego środka bezpieczeństwa. Nieszyfrowane logowanie do serwera, na którym znajdują się dane klientów lub dane z formularzy kontaktowych, trudno więc uzasadnić. Resztę przepisu i podejście oparte na ryzyku wyjaśnia nasz artykuł o art. 32 RODO dla WordPress.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.