Jak tworzyć klucze SSH za pomocą OpenSSH na macOS lub Linux

Uwierzytelnianie oparte na kluczach SSH jest branżowym standardem zabezpieczania zdalnego dostępu do serwerów. Zamiast przesyłać hasło przez sieć, klient udowadnia swoją tożsamość, rozwiązując kryptograficzne wyzwanie, na które może odpowiedzieć tylko posiadacz klucza prywatnego — serwer nigdy nie widzi samego klucza prywatnego.

Para kluczy SSH składa się z dwóch matematycznie powiązanych plików: klucza prywatnego (przechowywanego wyłącznie na lokalnym komputerze, nigdy nieudostępnianego) oraz klucza publicznego (wdrażanego na każdym serwerze, do którego potrzebujesz dostępu). Gdy inicjujesz połączenie, OpenSSH używa uzgadniania challenge-response, aby zweryfikować, że Twój klucz prywatny odpowiada kluczowi publicznemu na serwerze, przyznając dostęp bez monitu o hasło.

Dlaczego klucze SSH są zdecydowanie lepsze od uwierzytelniania hasłem

Hasła są podatne na ataki brute-force, credential stuffing, phishing oraz przechwycenie w źle skonfigurowanych sieciach. Klucze SSH eliminują wszystkie te wektory ataku jednocześnie.

• Siła kryptograficzna: Klucz RSA 4096-bitowy lub klucz Ed25519 jest obliczeniowo niemożliwy do złamania metodą brute-force przy użyciu obecnego sprzętu.
• Żaden sekret nie jest przesyłany przez sieć: Klucz prywatny nigdy nie opuszcza Twojego komputera. Protokół uwierzytelniania dowodzi posiadania bez ujawniania.
• Gotowość do automatyzacji: Potoki CI/CD, playbooki Ansible, zadania rsync i kopie zapasowe oparte na cron wymagają uwierzytelniania nieinteraktywnego. Klucze SSH umożliwiają to bez osadzania haseł w postaci zwykłego tekstu w skryptach.
• Możliwość audytu: Każda para kluczy może być jednoznacznie identyfikowana przez swój odcisk palca, co ułatwia unieważnienie pojedynczego skompromitowanego klucza bez rotacji poświadczeń wszędzie.
• Zgodność z listami ACL authorized_keys: Możesz ograniczyć konkretny klucz publiczny do uruchamiania tylko jednego polecenia, powiązać go ze źródłowym IP lub zapobiec przekierowaniu portów — kontrole, których uwierzytelnianie hasłem nie może replikować.

Jeśli zarządzasz VPS lub serwerem dedykowanym, całkowite wyłączenie uwierzytelniania hasłem i wymuszenie logowania wyłącznie kluczem jest jednym z najskuteczniejszych kroków wzmacniania bezpieczeństwa, jakie możesz podjąć.

Wybór odpowiedniego algorytmu klucza

Oryginalna dokumentacja OpenSSH i większość starszych samouczków domyślnie używa RSA. Dziedzina poszła naprzód. Oto precyzyjne porównanie każdego algorytmu obsługiwanego przez ssh-keygen dzisiaj:

Ed25519 jest właściwym domyślnym wyborem w 2024 roku. Generuje krótsze klucze, podpisuje szybciej, a jego stały rozmiar klucza eliminuje ryzyko przypadkowego wygenerowania zbyt małego klucza. RSA przy 4096 bitach pozostaje akceptowalny dla środowisk, które muszą współpracować ze starszymi systemami sprzed obsługi Ed25519 (OpenSSH < 6.5, wydany w 2014 roku).

Wymagania wstępne

• Stacja robocza z systemem macOS lub Linux z zainstalowanym OpenSSH. Oba systemy operacyjne domyślnie dostarczają OpenSSH. Zweryfikuj za pomocą:

ssh -V

• Dostęp sieciowy do zdalnego serwera, na którym masz konto (root lub bez uprawnień).
• Podstawowa znajomość terminala.

W dystrybucjach Linux dostarczanych z minimalną instalacją (Alpine, niektóre instalacje sieciowe Debian), zainstaluj narzędzia klienckie za pomocą:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Krok 1: Otwórz terminal

macOS: Naciśnij Cmd + Space, wpisz Terminal i naciśnij Enter. Alternatywnie przejdź do Aplikacje > Narzędzia > Terminal. Zaawansowani użytkownicy mogą korzystać z iTerm2 lub wbudowanego terminala w VS Code.

Linux: Naciśnij Ctrl + Alt + T w większości środowisk graficznych lub uruchom emulator terminala swojej dystrybucji z menu aplikacji.

Krok 2: Wygeneruj parę kluczy SSH

Generowanie klucza Ed25519 (zalecane)

ssh-keygen -t ed25519 -C "your_email@example.com"

Flaga -C dodaje czytelny dla człowieka komentarz do klucza publicznego. Użyj swojego adresu e-mail, nazwy hosta lub opisowej etykiety, takiej jak "deploy-key-prod" — nie pełni żadnej funkcji kryptograficznej, ale jest nieoceniona podczas audytowania plików authorized_keys, które gromadzą dziesiątki wpisów.

Generowanie klucza RSA (zgodność ze starszymi systemami)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Używaj -b 4096 jawnie. Historyczna wartość domyślna 2048 bitów jest nadal technicznie akceptowalna, ale zapewnia mniejszy margines bezpieczeństwa wobec przyszłych postępów w algorytmach faktoryzacji. Nigdy nie używaj -b 1024 ani -b 2048 dla nowych kluczy, jeśli dostępne jest 4096.

Generowanie nazwanego klucza dla konkretnego hosta

Przy zarządzaniu wieloma serwerami lub rolami używaj odrębnych plików kluczy zamiast ponownie używać jednego klucza wszędzie. Skompromitowany klucz wpływa wtedy tylko na systemy, na których został wdrożony:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Krok 3: Wybierz lokalizację przechowywania

Po uruchomieniu ssh-keygen zobaczysz:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Naciśnij Enter, aby zaakceptować wartość domyślną (~/.ssh/id_ed25519 dla Ed25519, ~/.ssh/id_rsa dla RSA), lub wpisz niestandardową ścieżkę. Domyślna lokalizacja jest odpowiednia dla pojedynczego klucza ogólnego przeznaczenia. W przypadku kluczy specyficznych dla roli zawsze podawaj opisową nazwę pliku, jak pokazano w poprzednim kroku.

Ważna uwaga dotycząca uprawnień plików: Katalog ~/.ssh/ musi mieć tryb 700, a pliki kluczy prywatnych muszą mieć tryb 600. OpenSSH odmówi użycia kluczy z nadmiernie liberalnymi uprawnieniami i wyświetli ostrzeżenie. Jeśli kiedykolwiek kopiujesz klucze między maszynami, natychmiast zweryfikuj uprawnienia:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Krok 4: Ustaw hasło

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Hasło szyfruje plik klucza prywatnego na dysku przy użyciu AES-256-CBC (w nowoczesnym OpenSSH). Jeśli atakujący uzyska Twój plik klucza prywatnego — poprzez skradziony laptop, skompromitowaną kopię zapasową lub źle skonfigurowany snapshot chmury — silne hasło jest ostatnią linią obrony uniemożliwiającą jego użycie.

Kiedy pominąć hasło: Zautomatyzowane konta usług (potoki wdrożeniowe, agenty kopii zapasowych) działające bez nadzoru w uzasadniony sposób potrzebują kluczy bez hasła. W takim przypadku ogranicz uprawnienia klucza po stronie serwera używając opcji authorized_keys (patrz sekcja zaawansowana poniżej) i przechowuj klucz prywatny w menedżerze sekretów, a nie w współdzielonym systemie plików.

Po potwierdzeniu hasła OpenSSH wyświetla odcisk palca klucza i obraz randomart:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Zapisz odcisk palca. Użyjesz go do weryfikacji tożsamości klucza podczas audytowania serwerów.

Krok 5: Skopiuj klucz publiczny na zdalny serwer

Metoda 1: ssh-copy-id (najszybsza)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Flaga -i jawnie określa, który klucz publiczny skopiować, zapobiegając przesłaniu przez ssh-copy-id każdego klucza z agenta. Zostaniesz poproszony o hasło serwera raz. Narzędzie automatycznie obsługuje tworzenie katalogów, dołączanie do pliku i ustawianie uprawnień.

Metoda 2: Ręczne wdrożenie (gdy ssh-copy-id jest niedostępny)

To właściwe podejście, gdy zdalny system to Windows, urządzenie sieciowe lub kontener bez ssh-copy-id w ścieżce.

Najpierw wyświetl swój klucz publiczny:

cat ~/.ssh/id_ed25519.pub

Skopiuj całe wyjście — jest to pojedyncza linia zaczynająca się od ssh-ed25519 (lub ssh-rsa). Następnie zaloguj się na serwer i dołącz go:

ssh user@your-server.com

Po połączeniu:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Częsty błąd: Użycie > zamiast >> nadpisuje cały plik authorized_keys, blokując każdy inny klucz. Zawsze używaj >> do dołączania.

Metoda 3: Przesłanie przez SSH w jednym poleceniu

Jeśli masz już dostęp hasłem i chcesz wdrożyć bez interaktywnego logowania:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Krok 6: Przetestuj połączenie

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Pomyślne połączenie bez monitu o hasło (lub tylko z monitem o hasło dla lokalnego klucza) potwierdza, że konfiguracja jest prawidłowa. Jeśli połączenie nie powiedzie się, uruchom z pełnym wyjściem diagnostycznym:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

Flaga -vvv wyświetla pełny dziennik negocjacji, pokazując dokładnie, który klucz został zaoferowany, czy serwer go zaakceptował i gdzie uzgadnianie nie powiodło się.

Krok 7: Skonfiguruj ~/.ssh/config dla trwałych profili hostów

Wpisywanie pełnego ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 za każdym razem jest podatne na błędy i powolne. Plik konfiguracyjny klienta SSH eliminuje ten problem:

nano ~/.ssh/config

Dodaj blok hosta:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Teraz połącz się po prostu za pomocą:

ssh prod-web

Ten wzorzec skaluje się sprawnie do dziesiątek serwerów i jest niezbędny dla każdego inżyniera zarządzającego infrastrukturą na dużą skalę. Dyrektywa ServerAliveInterval 60 wysyła pakiet keepalive co 60 sekund, zapobiegając przerywaniu bezczynnych połączeń przez zapory sieciowe — częsta frustracja u dostawców chmury.

Zarządzanie wieloma kluczami za pomocą agenta SSH

Agent SSH przechowuje odszyfrowane klucze prywatne w pamięci przez czas trwania sesji, dzięki czemu hasło wprowadzasz raz, a nie przy każdym połączeniu.

Uruchom agenta i dodaj klucz:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

W systemie macOS możesz utrwalić klucze między restartami, dodając następujące wpisy do ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Dyrektywa UseKeychain yes integruje się z pękiem kluczy macOS, przechowując hasło bezpiecznie, tak że przeżywa restarty systemu.

Wyświetl wszystkie klucze aktualnie załadowane w agencie:

ssh-add -l

Usuń konkretny klucz z agenta:

ssh-add -d ~/.ssh/id_ed25519

Zaawansowane: Ograniczanie kluczy w authorized_keys

Plik authorized_keys obsługuje opcje per-klucz, które drastycznie zmniejszają zasięg skutków skompromitowanego klucza. Są one umieszczane przed typem klucza w tej samej linii:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Te opcje są szczególnie cenne dla kluczy wdrożeniowych na serwerach dedykowanych, gdzie pojedynczy skompromitowany klucz CI/CD nie powinien przyznawać pełnego dostępu do powłoki.

Wzmacnianie demona SSH po wdrożeniu kluczy

Gdy uwierzytelnianie oparte na kluczach działa, całkowicie wyłącz uwierzytelnianie hasłem na serwerze. Edytuj /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Ustaw następujące dyrektywy:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Przeładuj demona bez rozłączania bieżącej sesji:

sudo systemctl reload sshd

Nie zamykaj istniejącej sesji SSH przed przetestowaniem nowego połączenia w osobnym terminalu. Błędna konfiguracja, która Cię zablokuje, jest możliwa do naprawienia z konsoli, ale jest uciążliwa i możliwa do uniknięcia.

W przypadku serwerów działających w środowiskach cPanel VPS pamiętaj, że niektóre wersje cPanel zarządzają własną konfiguracją SSH. Sprawdź, czy zmiany w sshd_config są zachowywane po aktualizacjach cPanel, sprawdzając /etc/ssh/sshd_config.d/ pod kątem plików nadpisujących.

Rotacja i unieważnianie kluczy SSH

Rotacja kluczy to praktyka higieny bezpieczeństwa, która ogranicza okno ekspozycji w przypadku cichego skompromitowania klucza. Praktyczny harmonogram rotacji to co 12 miesięcy dla kluczy osobistych i co 90 dni dla kluczy kont usług.

Aby unieważnić klucz: Usuń jego linię z ~/.ssh/authorized_keys na każdym serwerze, na którym został wdrożony. W standardowym OpenSSH nie ma centralnego mechanizmu unieważniania — dlatego ważne jest prowadzenie inwentarza miejsc, gdzie wdrożony jest każdy odcisk palca klucza.

Aby dokonać rotacji klucza:

1. Wygeneruj nową parę kluczy.
2. Wdróż nowy klucz publiczny na wszystkich docelowych serwerach.
3. Przetestuj łączność z nowym kluczem.
4. Usuń stary klucz publiczny ze wszystkich plików authorized_keys.
5. Usuń lub zarchiwizuj stary klucz prywatny lokalnie.

W środowiskach z hostingiem VPS w wielu regionach, narzędzie do zarządzania konfiguracją, takie jak Ansible, jest praktycznym rozwiązaniem do propagowania rotacji kluczy na dużą skalę.

Przenoszenie kluczy między maszynami

Gdy konfigurujesz nową stację roboczą, musisz przenieść istniejące klucze prywatne zamiast generować nowe (co wymagałoby ponownego wdrożenia kluczy publicznych wszędzie).

Skopiuj klucz prywatny bezpiecznie używając scp lub rsync przez SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Alternatywnie użyj zaszyfrowanego dysku USB lub menedżera haseł obsługującego przechowywanie kluczy SSH (1Password, Bitwarden i HashiCorp Vault obsługują to). Nigdy nie wysyłaj kluczy prywatnych e-mailem ani nie przechowuj ich w niezaszyfrowanym magazynie w chmurze.

Po przeniesieniu natychmiast zweryfikuj uprawnienia na nowej maszynie:

chmod 600 ~/.ssh/id_ed25519

Weryfikacja odcisku palca klucza hosta serwera

Przy pierwszym połączeniu z serwerem OpenSSH przedstawia odcisk palca klucza hosta serwera i prosi o jego potwierdzenie:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Nigdy nie wpisuj yes bezmyślnie. Uzyskaj oczekiwany odcisk palca przez kanał pozapasmowy — panel sterowania Twojego dostawcy hostingu, współpracownika, który skonfigurował serwer, lub wyjście konsoli serwera. Ten krok zapobiega atakom man-in-the-middle. W środowiskach hostingu współdzielonego oczekiwany odcisk palca jest zazwyczaj wymieniony w panelu sterowania w ustawieniach dostępu SSH.

Po zaakceptowaniu odcisk palca jest przechowywany w ~/.ssh/known_hosts. Jeśli odcisk palca nieoczekiwanie zmieni się przy kolejnym połączeniu, OpenSSH odmówi połączenia i wyświetli ostrzeżenie — traktuj to jako poważne zdarzenie bezpieczeństwa wymagające zbadania przed kontynuowaniem.

Macierz decyzyjna i lista kontrolna techniczna

Użyj tej listy kontrolnej przed uznaniem konfiguracji kluczy SSH za gotową do produkcji:

• [ ] Algorytm klucza to Ed25519 (lub RSA 4096 dla zgodności ze starszymi systemami) — DSA i ECDSA 256 nie są akceptowalne dla nowych wdrożeń
• [ ] Uprawnienia pliku klucza prywatnego to 600; uprawnienia katalogu ~/.ssh/ to 700
• [ ] Silne hasło jest ustawione na wszystkich kluczach użytkowników interaktywnych
• [ ] Klucze kont usług bez haseł są ograniczone za pomocą opcji authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no jest ustawiony w /etc/ssh/sshd_config na wszystkich serwerach
• [ ] PermitRootLogin prohibit-password lub PermitRootLogin no jest wymuszony
• [ ] Odciski palców kluczy hosta serwera zostały zweryfikowane pozapasmowo
• [ ] Istnieje inwentarz kluczy mapujący każdy odcisk palca na serwery, na których jest wdrożony
• [ ] Harmonogram rotacji kluczy jest zdefiniowany i zaplanowany w kalendarzu
• [ ] Bloki hosta ~/.ssh/config są skonfigurowane, aby uniknąć ręcznego używania flagi -i
• [ ] Agent SSH jest używany, aby uniknąć wielokrotnego wprowadzania hasła podczas sesji roboczych
• [ ] Wpisy known_hosts są okresowo przeglądane pod kątem nieaktualnych lub nieoczekiwanych wpisów

FAQ

Jaka jest różnica między kluczami SSH Ed25519 i RSA?

Ed25519 używa kryptografii krzywych eliptycznych ze stałym kluczem 256-bitowym, który zapewnia około 128 bitów bezpieczeństwa, podpisuje operacje szybciej niż RSA i generuje krótsze ciągi kluczy. RSA przy 4096 bitach zapewnia porównywalne bezpieczeństwo, ale jest wolniejszy i generuje większy materiał klucza. Używaj Ed25519 dla wszystkich nowych kluczy, chyba że musisz połączyć się z systemem działającym na OpenSSH starszym niż wersja 6.5.

Czy mogę używać tej samej pary kluczy SSH dla wielu serwerów?

Tak, technicznie. Jednak najlepszą praktyką jest używanie odrębnych par kluczy dla każdej roli lub środowiska (dostęp z osobistej stacji roboczej, wdrożenie CI/CD, konserwacja bazy danych). Ogranicza to wpływ pojedynczego skompromitowanego klucza i sprawia, że unieważnienie jest proste bez zakłócania niepowiązanych systemów.

Co się stanie, jeśli utracę klucz prywatny?

Tracisz możliwość uwierzytelniania za pomocą tej pary kluczy. Klucz publiczny na serwerze staje się bezużyteczny. Musisz uzyskać dostęp do serwera alternatywną metodą — dostępem przez konsolę, dodatkowym kluczem lub awaryjnym dostępem dostawcy hostingu — a następnie usunąć osierocony klucz publiczny z authorized_keys i wdrożyć nową parę kluczy.

Dlaczego SSH nadal prosi o hasło po skopiowaniu klucza publicznego?

Najczęstsze przyczyny to: nieprawidłowe uprawnienia do ~/.ssh/ (musi być 700) lub ~/.ssh/authorized_keys (musi być 600) na serwerze; katalog domowy jest zapisywalny przez wszystkich; SELinux lub AppArmor blokuje dostęp do katalogu .ssh; lub PubkeyAuthentication no jest ustawiony w /etc/ssh/sshd_config. Uruchom ssh -vvv, aby dokładnie zidentyfikować, która metoda uwierzytelniania jest próbowana i odrzucana.

Jak usunąć klucz SSH z serwera, do którego nie mam już dostępu?

Jeśli nie masz innej metody uwierzytelniania, skontaktuj się z zespołem wsparcia swojego dostawcy hostingu lub użyj pozapasmowego dostępu przez konsolę (dostępnego dla klientów VPS i serwera dedykowanego), aby zalogować się i bezpośrednio edytować ~/.ssh/authorized_keys. Dlatego utrzymywanie poświadczeń dostępu do konsoli oddzielnie od kluczy SSH jest bezwzględnym wymogiem operacyjnym.