Świeży serwer VPS dostaje pierwsze pukanie od botów kilka minut po starcie. Zamiast wykładu o ośmiu krokach dostajesz jedną wklejkę do Claude Code - agent robi audyt, zabezpiecza serwer i pokazuje różnicę. Ty tylko potwierdzasz.
root) oraz hasło albo klucz SSH dodany w panelu hostingu.Gdzie to znaleźć na Hostingerze: hPanel → VPS → Manage przy Twoim serwerze. Na stronie Overview masz wszystko: adres IPv4 i nazwę użytkownika w karcie z danymi VPS-a, a obok nazwy serwera, pod Root access, gotową do skopiowania komendę SSH. Hasło to te, które ustawiłeś przy tworzeniu serwera - panel go nie pokaże; jeśli go nie pamiętasz, kliknij Change pod „Root password" i ustaw nowe. Jest tam też przycisk Terminal (prawy górny róg) - konsola w przeglądarce, logująca Cię automatycznie, gdyby SSH z komputera jeszcze nie działało.
Jedna żelazna zasada: przez cały proces trzymaj otwarte drugie okno terminala zalogowane na serwer. Zmiany w SSH robi się z siatką bezpieczeństwa - już zalogowanej sesji nic nie zrywa, więc gdyby coś poszło nie tak, tamto okno jest Twoją drogą powrotną. Agent też będzie tego pilnował, ale pas i szelki jeszcze nikomu nie zaszkodziły.
Nowy folder, żeby agent miał czyste biurko. Wpisz w terminalu na swoim komputerze:
mkdir vps-hardening && cd vps-hardening && claude
Po chwili patrzysz na okno rozmowy z agentem. To wszystko, co musisz umieć z terminala.
Pracujesz w aplikacji desktopowej Claude Code? Terminal nie jest Ci potrzebny w ogóle: utwórz pusty folder w Finderze albo Eksploratorze, otwórz go w apce jako nową sesję lokalną i przejdź od razu do Kroku 2. Wszystko dalej wygląda identycznie.
Całość, jednym wklejeniem. W prompcie jest wszystko: skąd wziąć skrypty, w jakiej kolejności iść i czego pilnować, żebyś nie stracił dostępu do serwera.
Sklonuj repozytorium https://github.com/Szewowsky/vps-security.git do bieżącego katalogu, przeczytaj plik .claude/commands/hardening.md i przeprowadź mnie przez opisany tam wizard zabezpieczenia serwera VPS - dokładnie według jego zasad bezpieczeństwa i kolejności faz. Idź krok po kroku: czekaj na wynik każdej komendy i nie przechodź dalej, jeśli test kroku nie przeszedł. Zacznij od zebrania danych (Faza 0), potem audyt PRZED, hardening, audyt PO - i na końcu pokaż mi zestawienie: co było na czerwono, a co jest teraz na zielono. Przez cały czas pilnuj, żebym nie stracił dostępu do serwera.
Agent zapyta Cię o IP, port, login i nazwę nowego użytkownika. Odpowiadasz normalnie, po ludzku - resztę robi sam.
Agent pyta o IP, port, login, hasło i nazwę nowego użytkownika, po czym sprawdza, czy Twój klucz SSH działa na serwerze. Jeśli dodałeś go w panelu hostingu - idzie dalej bez hasła. Jeśli nie - sam go wgrywa (stąd pytanie o hasło), a gdy klucza w ogóle nie masz, najpierw go wygeneruje.
Agent odpala skrypt audytu na serwerze. Na świeżej maszynie zobaczysz sporo czerwonego - to jest punkt odniesienia, do którego wrócimy na końcu.
Powstaje zwykłe konto z uprawnieniami sudo. Agent najpierw testuje logowanie nowym userem, dopiero potem wyłącza roota. Nigdy odwrotnie.
Logowanie hasłem znika - zostaje klucz, którego nie da się zgadywać. Do tego limity prób i kilka porządków w konfiguracji.
Agent zapyta, czy zmienić port na niestandardowy. Mniej szumu botów w logach, ale to kosmetyka, nie zamek - a niektóre sieci blokują niestandardowe porty. Nie wiesz? Zostaw domyślny, tak jest bezpiecznie.
Domyślnie nic nie wchodzi, wyjątek dostaje SSH. Agent dopisuje wyjątek zanim włączy zaporę - kolejność, która ratuje przed zatrzaśnięciem drzwi.
Kilka nieudanych logowań z jednego adresu i adres wylatuje na bana. Bot dostaje ciszę zamiast kolejnych podejść.
System sam dociąga łatki bezpieczeństwa. Jedna rzecz mniej na głowie, na zawsze.
Ten sam skrypt jeszcze raz. Te same pozycje, tym razem na zielono. To jest cały dowód - i moment, w którym możesz zamknąć zapasowy terminal.
Przy każdej ryzykownej zmianie agent zatrzymuje się i pyta. Jeśli jakiś krok się wysypie, nie brnie dalej na ślepo - pokazuje błąd i czeka na Ciebie. Tak jest napisany wizard.
Na końcu agent pokaże Ci porównanie audytów. Powinno wyglądać mniej więcej tak:
━━━ Użytkownik (non-root) ━━━ [FAIL] Brak użytkownika z sudo — logujesz się jako root! → [PASS] ━━━ SSH ━━━ [FAIL] Logowanie hasłem włączone → [PASS] [FAIL] Root może logować się przez SSH → [PASS] ━━━ Firewall / Fail2ban ━━━ [FAIL] UFW nieaktywny → [PASS] [FAIL] Fail2ban niezainstalowany → [PASS]
Dwa szybkie testy własnoręczne, dla spokoju ducha (podmień dane na swoje):
# nowy użytkownik wchodzi: ssh -p TWOJ_PORT twoj_user@TWOJE_IP "echo OK" # a root już nie (to jest DOBRA wiadomość): ssh -p TWOJ_PORT root@TWOJE_IP
Pierwsza komenda ma zwrócić OK, druga ma Cię odrzucić. Jeśli tak jest - serwer stoi, drzwi są Twoje.
Serwer zabezpieczony, agent na nim mieszka. Teraz właściwa część odcinka: jak się do niego
wpinać na co dzień. Wszystkie trzy drogi korzystają z tego samego aliasu w
~/.ssh/config - robisz go raz.
Kliknij metodę, żeby rozwinąć instrukcję krok po kroku.
Cała robota to jeden wpis w pliku konfiguracyjnym SSH. Otwierasz plik (jeśli nie istnieje, komenda utworzy pusty - to normalne):
nano ~/.ssh/config
I dopisujesz te linijki, podmieniając adres, użytkownika i port na swoje (adres i użytkownika masz w panelu hostingu; port to 22, chyba że zmieniałeś go przy hardeningu):
Host vps
HostName 11.22.33.44
User twoj-uzytkownik
Port 22
IdentityFile ~/.ssh/id_ed25519
Zapisujesz (Ctrl+O, Enter,
Ctrl+X) i sprawdzasz:
chmod 600 ~/.ssh/config ssh vps
Jesteś na serwerze - od teraz to jedno słowo zastępuje całą komendę z portem, userem i adresem.
Agenta uruchamiasz w tmux, żeby praca nie ginęła
razem z zamkniętym oknem:
ssh vps tmux new -s praca claude
Wychodzisz bez zabijania sesji: Ctrl+B, potem
D. Wracasz później:
ssh vps i
tmux attach -t praca.
Na Ubuntu tmux zwykle jest od razu - jeśli serwer odpowie „command not found", doinstalujesz go
jedną komendą: sudo apt install -y tmux.
Ściąga tmux na co dzień:
tmux ls # lista wszystkich sesji tmux new -s praca # nowa sesja o nazwie "praca" tmux attach -t praca # wejście do istniejącej sesji # Ctrl+B, potem D # wyjście BEZ zabijania sesji tmux kill-session -t praca # usunięcie jednej sesji tmux kill-server # ubija wszystkie sesje naraz
Drobiazg, który potrafi zmylić: sesja tmux pamięta środowisko z chwili
startu. Jeśli coś doinstalowałeś (np. claude), gdy sesja
już działała, w jej środku wpisz source ~/.bashrc -
albo załóż sesję od nowa.
claude: command not found?
Szablony hostingowe instalują Claude Code tylko dla roota - Twój nowy użytkownik go nie widzi.
Trzy wyjścia: wizard z Kroku 2 sam to wykryje i zapyta, czy doinstalować; aplikacja desktopowa
(droga 02) zainstaluje agenta automatycznie przy pierwszym połączeniu; albo ręcznie, bez roota:
curl -fsSL https://claude.ai/install.sh | bash.
Local i Cloud).vps. Name to dowolna etykieta,
a SSH port i SSH key zostaw puste - aplikacja
sama pisze pod polami, że weźmie je z ~/.ssh/config.Nie robiłeś Drogi 1? Alias vps
działa tylko wtedy, gdy istnieje wpis w ~/.ssh/config.
Bez niego też się połączysz - wpisz w SSH host pełną formę
uzytkownik@adres-serwera i uzupełnij SSH port
ręcznie. Alias to wygoda, nie wymóg - ale robisz go raz i działa też w terminalu i edytorze.
Po lewej stronie zobaczysz drzewo plików. To nie jest Twój dysk - to serwer. Klikasz plik, edytujesz, zapisujesz, i zostaje tam.
Test zamkniętej klapy - to, po co w ogóle się tu wpinasz: zleć agentowi zadanie na dwie, trzy minuty → zamknij aplikację, dla pewności także klapę laptopa → wróć, otwórz to samo połączenie. Zadanie czeka gotowe, pliki na miejscu. Serwer nie idzie spać razem z Tobą.
ssh vps - Warp jest terminalem,
więc czyta ten sam ~/.ssh/config.~/.warp/),
bez roota i bez otwierania portów.~/.warp*/remote-server na serwerze.Cmd/Ctrl+Shift+P →
„Remote-SSH: Connect to Host" - na liście zobaczysz vps,
bo wtyczka czyta ten sam ~/.ssh/config.Kompletna instrukcja połączenia (gotowy prompt dla agenta, tabela "czego się nie spodziewać", najczęstsze potknięcia) czeka w osobnym gotowcu: POLACZENIE-Z-KOMPUTERA.md - też w dwóch trybach: prompt dla agenta albo pięć minut ręcznie.
Jedna różnica, o której warto wiedzieć: aplikacja Claude Code instaluje agenta
na serwerze sama. Codex tego nie robi - jego aplikacja wymaga, żeby codex
był już wgrany na serwerze, inaczej się nie połączy.
Rzeczy, na których sam się przyciąłem, żebyś Ty nie musiał:
chmod 600 na pliku klucza i po sprawie.! -
wpisany wprost w terminalu potrafi się popsuć. Bezpieczniej podawać przez printf
i standardowe wejście, nie jako argument./root, opakowujesz w sudo.Connection refused), nie zawieszone. Dlatego wizard
wpisuje Twój adres do listy wyjątków przed instalacją fail2ban - nie tylko przed
restartem, bo pakiet uruchamia jail już w trakcie apt-get install. Jeśli mimo to Cię
odetnie - wejdź konsolą z panelu hostingu albo z innego adresu i odbanuj się:
sudo fail2ban-client set sshd unbanip TWOJE_IP.Cały ten poradnik zaczyna się od serwera. Ja swoje trzymam u Hostingera - to partner technologiczny kanału, więc z kodem ROBERTHOST dostajesz dodatkowy rabat, a ja małą prowizję. Sprzęt bez zmian, cena niższa.