Jak bezpiecznie dać komuś dostęp do serwera strony — i co zrobić, gdy naprawa się skończy

Naprawa strony wymaga dostępu do plików. Nie da się tego obejść: ktoś, kto ma usunąć malware, musi móc czytać i zmieniać pliki na serwerze. Pytanie brzmi, jaki dostęp dać, żeby wykonawca mógł pracować, a Ty nie musiał mu ufać bezgranicznie. Poniżej zasady, które stosujemy sami i których radzimy wymagać od każdego, komu zlecasz pracę.

Zasada 1: SFTP lub SSH, nie FTP

Zwykłe FTP przesyła hasło i pliki bez szyfrowania. Każdy, kto jest po drodze (otwarte Wi‑Fi, zainfekowany komputer, podsłuch u operatora), widzi hasło w czystej postaci. Większość polskich hostingów współdzielonych daje SFTP (port 22) albo FTPS. Jeśli Twój hosting daje tylko FTP, to pierwsza rzecz do zmiany, niezależnie od naprawy.

SSH (dostęp do powłoki) jest jeszcze lepszy, bo pozwala wykonawcy uruchamiać narzędzia na serwerze zamiast ściągać setki tysięcy plików. Skanowanie przez SFTP strony z 400 tys. plików trwa godziny, przez SSH minuty. Jeśli hosting ma SSH, włącz go na czas naprawy.

Zasada 2: osobne konto, nie główne

Panel hostingu pozwala zwykle założyć dodatkowe konto FTP/SFTP z dostępem tylko do wybranego katalogu. Załóż je na czas naprawy. Wykonawca dostaje dostęp do katalogu strony, nie do poczty, nie do innych domen na koncie, nie do ustawień hostingu. Po zakończeniu pracy usuwasz konto, a nie musisz zmieniać własnego hasła.

Nigdy nie wysyłaj hasła do panelu hostingu. Nie jest potrzebne do naprawy plików.

Zasada 3: klucz zamiast hasła, jeśli się da

Przy SSH wykonawca może podać swój klucz publiczny; wpisujesz go do ~/.ssh/authorized_keys na serwerze. Klucz nie wycieknie z wiadomości e‑mail, nie da się go podejrzeć, a usunięcie jednej linii cofa dostęp. Jeśli hosting nie obsługuje kluczy, hasło wygeneruj losowe i przekaż innym kanałem niż login (np. login mailem, hasło SMS‑em albo przez link jednorazowy).

Zasada 4: dostęp do bazy tylko jeśli jest potrzebny

Infekcja bywa w bazie, więc wykonawca może poprosić o dane do niej. Zwykle ma je już w wp-config.php lub configuration.php, bo to pliki na serwerze. Osobne hasło do phpMyAdmin nie jest konieczne. Jeśli dajesz, załóż osobnego użytkownika bazy z dostępem tylko do bazy strony.

Zasada 5: wymagaj kopii i dziennika zmian

Przed rozpoczęciem pracy wykonawca robi kopię plików i bazy (albo robisz ją Ty). Po zakończeniu dostajesz listę zmian: które pliki przeniesiono, które przywrócono, co zmieniono w bazie. Bez dziennika nie wiesz, co się stało z Twoją stroną, i nie masz jak sprawdzić, czy wykonawca nie zostawił czegoś swojego.

Co zrobić po zakończeniu naprawy

Lista do odhaczenia, w tej kolejności:

1. Sprawdź stronę z komputera, z telefonu w trybie prywatnym, z wyników Google. Formularze, koszyk, logowanie do panelu.
2. Usuń konto tymczasowe SFTP/SSH wykonawcy albo linię z kluczem w authorized_keys.
3. Zmień hasła, które wykonawca mógł zobaczyć w plikach: baza danych (i wpis w pliku konfiguracyjnym), klucze API w ustawieniach wtyczek, hasła SMTP w konfiguracji poczty strony.
4. Zmień sole i klucze sesji (AUTH_KEY i spółka w WordPressie, secret w Joomli). Unieważnia to wszystkie sesje, także ewentualną sesję wykonawcy w panelu CMS‑a.
5. Przejrzyj konta administratorów w CMS‑ie. Konto założone na czas naprawy usuń.
6. Sprawdź zaplanowane zadania (cron) na koncie hostingowym. Nie powinno tam być niczego nowego.
7. Zachowaj dziennik zmian i kopię sprzed naprawy poza serwerem, przez co najmniej kilka miesięcy.
8. Wyłącz SSH, jeśli nie korzystasz z niego na co dzień, a hosting pozwala to zrobić jednym kliknięciem.

Jak to wygląda w CleanOps

Dane dostępowe zapisujemy zaszyfrowane i używamy ich wyłącznie do połączenia z Twoim serwerem w trakcie skanu, naprawy i asystenta. Pracujemy na koncie, które nam podasz, bez uprawnień administratora serwera. Wszystkie zmiany są odwracalne, a dziennik jest w panelu. Po naprawie radzimy zrobić dokładnie to, co powyżej: usunąć konto tymczasowe albo zmienić hasło. Zapisane dane dostępowe możesz w każdej chwili nadpisać nowymi w panelu.