Bezpieczne SSH na Zawsze: Klucze Zamiast Hasła
Jeśli pracujesz z serwerami VPS, wiesz, że bezpieczeństwo to podstawa. Logowanie hasłem jest jak zostawienie kluczy do domu pod wycieraczką – działa, ale naraża Cię na boty i ataki.
Prawdziwym standardem branżowym jest uwierzytelnianie kluczem SSH. Jest ono nie tylko bezpieczniejsze, ale i znacznie wygodniejsze, ponieważ eliminuje konieczność wpisywania hasła przy każdym połączeniu.
Poniżej znajdziesz kompletny przewodnik, jak przejść na klucze, jak unikać typowych błędów (jak konflikty uprawnień, które często napotykamy!) i jak zarządzać wieloma serwerami VPS.
Krok 1: Tworzenie dedykowanych par kluczy (Lokalnie)
Dobrą praktyką jest posiadanie innej pary kluczy dla każdego serwera lub projektu. Dzięki temu, jeśli jeden klucz wycieknie lub zostanie skompromitowany, inne serwery pozostają bezpieczne.
Wygeneruj klucz na swoim komputerze lokalnym (andre-iMacUbuntu), nadając mu unikalną nazwę (np. odpowiadającą IP lub nazwie serwera).
# Używamy algorytmu ED25519 (nowszy i bezpieczniejszy niż RSA)
# Klucz prywatny zostanie zapisany jako ~/.ssh/klucz_158_220_88_64
ssh-keygen -t ed25519 -f ~/.ssh/klucz_158_220_88_64

Podczas generowania zostaniesz poproszony o:
- Podanie hasła (Passphrase): Zdecydowanie polecam! To hasło chroni Twój klucz prywatny na wypadek jego kradzieży. Będziesz je musiał podać raz, gdy dodasz klucz do agenta SSH (patrz Krok 4).
- Lokalizację: W naszym przykładzie jest to
~/.ssh/klucz_158_220_88_64.
W Twoim katalogu ~/.ssh pojawią się dwa pliki:
klucz_158_220_88_64(KLUCZ PRYWATNY – trzymasz go u siebie!)klucz_158_220_88_64.pub(KLUCZ PUBLICZNY – przesyłasz na serwer)
Alternatywna metoda: Generator Kluczy w Vaultwarden/Bitwarden
Jeśli używasz Vaultwarden (lub Bitwarden), możesz pominąć ręczne generowanie kluczy w konsoli. Menedżery haseł oferują wbudowany generator par kluczy SSH, który jest niezwykle wygodny:
- Wystarczy utworzyć nowy element i wybrać typ „Klucz SSH”.
- Generator tworzy parę kluczy (Prywatny + Publiczny) i bezpiecznie przechowuje klucz prywatny zaszyfrowany Twoim hasłem głównym.
- Z tak wygenerowanego klucza kopiujesz tylko jego Publiczną część i przechodzisz do Kroku 3.
Ważne dla ciągłości dostępu: Przechowywanie kluczy prywatnych w chmurze Vaultwarden/Bitwarden zabezpiecza Cię przed awarią sprzętową. Jeśli Twój komputer lokalny ulegnie uszkodzeniu i nie masz kopii zapasowej kluczy, utracisz dostęp do wszystkich serwerów, do których logowanie hasłem jest wyłączone. Wówczas jedynym rozwiązaniem jest łączenie się przez konsolę VNC/KVM, usuwanie starych kluczy i generowanie nowych. Dzięki Vaultwarden klucz prywatny jest zawsze dostępny i bezpieczny po zalogowaniu się na innym urządzeniu.

Krok 2: Konfiguracja Klienta SSH (~/.ssh/config)
Aby uniknąć wpisywania długich komend (ssh -i ... -p ...) za każdym razem, stwórz plik konfiguracyjny, który przypisze wszystkie ustawienia (w tym klucz) do wygodnego skrótu.
Utwórz lub edytuj plik ~/.ssh/config na swoim komputerze lokalnym:
nano ~/.ssh/config
Dodaj nowy blok konfiguracji dla swojego serwera (np. pod nazwą skrótową my_vps):
Host my_vps
HostName 158.220.88.64
User andre
Port 120
IdentityFile ~/.ssh/klucz_158_220_88_64
IdentitiesOnly yes
# Wymuś uwierzytelnianie tylko za pomocą klucza, blokując agenta.
Od teraz logujesz się tak: ssh my_vps

Bonus: Logowanie jednym kliknięciem w Terminalu Ubuntu
Jeśli używasz Terminala GNOME w Ubuntu, możesz wykorzystać funkcję Profili do logowania się jednym kliknięciem, bez konieczności wpisywania ssh my_vps.
- Otwórz Ustawienia Terminala: Kliknij menu hamburgera (trzy poziome kreski) lub prawym przyciskiem myszy na oknie terminala i wybierz „Ustawienia”.
- Przejdź do sekcji „Profile” i kliknij „Dodaj profil”.
- W zakładce „Command” (Komenda), w polu „Custom command” (Komenda niestandardowa), wpisz:
ssh my_vps - Nadaj profilowi czytelną nazwę, np. „SolutionsERP VPS”.
Teraz, gdy otworzysz nowy terminal, możesz szybko przełączyć się na ten profil z rozwijanej listy lub menu, a terminal automatycznie uruchomi komendę ssh my_vps, logując Cię natychmiast na serwerze!

Krok 3: Przesłanie Klucza Publicznego na Serwer
Użyj narzędzia ssh-copy-id, które automatycznie umieści Twój klucz publiczny w pliku ~/.ssh/authorized_keys na serwerze (będziesz musiał podać hasło serwerowe jeden ostatni raz):
ssh-copy-id -p 120 -i ~/.ssh/klucz_158_220_88_64.pub andre@158.220.88.64
Jeśli ssh-copy-id jest niedostępne, użyj komendy cat (musisz mieć włączone logowanie hasłem na serwerze, aby ta metoda zadziałała):
cat ~/.ssh/klucz_158_220_88_64.pub | ssh -p 120 andre@158.220.88.64 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'
Krok 4: Zabezpieczenie Plików i Wyłączenie Hasła (Na serwerze)
Po upewnieniu się, że logowanie kluczem działa, wykonaj dwa krytyczne kroki na serwerze:
A. Poprawne uprawnienia do plików
Problemy z uprawnieniami to najczęstsza przyczyna błędów. SSH jest rygorystyczne: klucze i katalogi muszą być dostępne tylko dla właściciela.
Zaloguj się na serwerze i upewnij się, że uprawnienia są takie:
# Katalog .ssh musi być dostępny tylko dla właściciela
chmod 700 /home/andre/.ssh
# Plik authorized_keys musi być czytelny i zapisywalny tylko przez właściciela
chmod 600 /home/andre/.ssh/authorized_keys
B. Wyłączenie Logowania Hasłem (Koniec z lukami)
Musisz edytować plik konfiguracyjny serwera SSH.
sudo nano /etc/ssh/sshd_config
Ustaw następujące dyrektywy:
PasswordAuthentication no # WYŁĄCZ logowanie hasłem
PermitRootLogin no # ZABLOKUJ logowanie bezpośrednio jako root
Zapisz plik i zrestartuj usługę SSH:
sudo systemctl restart ssh
UWAGA: Nie zamykaj bieżącej sesji serwera, dopóki nie przetestujesz nowego połączenia w nowym oknie!
Krok 5: Diagnozowanie Problemów i Agent SSH
Diagnoza problemów z uprawnieniami
Jeśli po restarcie usługi SSH nie możesz się zalogować kluczem, użyj trybu verbose (szczegółowego) na kliencie, aby zobaczyć, co poszło nie tak:
ssh -v my_vps
Jeśli w logach serwera (/var/log/auth.log) zobaczysz błąd w stylu „Authentication refused: bad ownership or modes”, oznacza to, że musisz ponownie sprawdzić uprawnienia katalogów (700 dla .ssh) i plików (600 dla kluczy).
Jak działa Agent SSH?
Agent SSH (ssh-agent) to program działający w tle, który utrzymuje Twoje klucze prywatne odblokowane w pamięci RAM po jednorazowym podaniu hasła (passphrase) klucza. Zamiast wpisywać hasło co połączenie, agent używa klucza za Ciebie.
Typowy błąd, który widzieliśmy:
sign_and_send_pubkey: signing failed for ED25519 "/home/andre/.ssh/id_ed25519" from agent: agent refused operation
Ten błąd pojawia się, gdy agent ma załadowane wiele kluczy, ale klient SSH używa klucza domyślnego, który:
- Nie pasuje do klucza publicznego na serwerze.
- Agent nie jest w stanie go użyć (np. nie ma podanego passphrase).
Rozwiązanie: Użycie dyrektywy IdentitiesOnly yes (w ~/.ssh/config) zmusza klienta SSH, by ignorował wszystko w agencie i używał tylko klucza, który jawnie mu podałeś w konfiguracji (IdentityFile).
Ostateczny test: Potwierdzenie wyłączenia hasła
Po restarcie usługi SSH, otwórz nowy terminal i spróbuj zalogować się, celowo wyłączając uwierzytelnianie kluczem:
ssh -o PubkeyAuthentication=no -p 120 andre@158.220.88.64
Oczekiwana reakcja: Natychmiastowe odrzucenie połączenia.
Permission denied (publickey).
Jeśli to widzisz, masz pewność, że nikt nie zaloguje się do Twojego serwera samym hasłem.




Dodaj komentarz