Klucze SSH (Kryptograficzne klucze SSH)

1. Przegląd koncepcji i problem systemowy

Tradycyjna autentykacja oparta na loginie i haśle w zdalnych serwerach posiada krytyczne wady architektoniczne: podatność na ataki brute-force, przechwycenie danych w przypadku kompromitacji kanału (man-in-the-middle) oraz czynnik ludzki (użycie słabych lub powtarzalnych haseł). W momencie, gdy port 22 staje się publicznie dostępny w internecie, botnety generują tysiące prób zgadywania haseł co minutę.

SSH Keys (Kryptograficzne klucze SSH) rozwiązują ten problem poprzez kryptografię asymetryczną. Użytkownik generuje parę matematycznie powiązanych kluczy:

• Private Key: Przechowywany wyłącznie na lokalnej maszynie dewelopera w zaszyfrowanej formie z użyciem passphrase i nigdy nie przesyłany przez sieć.
• Public Key: Umieszczany na docelowym serwerze w pliku ~/.ssh/authorized_keys.

Podczas handshake serwer generuje losowe wyzwanie (challenge), szyfruje je lub żąda podpisu od klienta przy użyciu private key. Autentykacja odbywa się poprzez matematyczne potwierdzenie posiadania private key bez ujawnienia samego sekretu.

+------------------+                    +--------------------+
|  Klient lokalny  |                    |  Serwer zdalny     |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Żądanie połączenia (User, PubKey)  |
         |--------------------------------------->|
         |                                        | 2. Weryfikacja obecności
         |                                        |    klucza publicznego
         |  3. Wyzwanie kryptograficzne (Nonce)   |
         |<---------------------------------------|
         |                                        |
         | 4. Podpisanie nonce kluczem prywatnym  |
         |--------------------------------------->|
         |                                        | 5. Walidacja podpisu
         |                                        |    kluczem publicznym
         |  6. Sesja otwarta (Authenticated)      |
         |<---------------------------------------|

2. Taksonomia architektury i model mentalny

Algorytmy kryptograficzne dla SSH ewoluowały wraz ze wzrostem mocy obliczeniowej i rozwojem kryptoanalizy:

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • Współczesny de facto złoty standard branży.
   • Opiera się na krzywej eliptycznej Curve25519.
   • Długość klucza: 256 bitów.
   • Wysoka odporność na ataki side-channel oraz timing-attack, błyskawiczna szybkość wykonania operacji.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Wykorzystuje standaryzowane krzywe NIST (np. nistp256 lub nistp521).
   • Posiada potencjalne ryzyko backdoorów w wyborze parametrów generatora NIST oraz krytyczną wrażliwość na jakość generatora liczb losowych (RNG): powtórzenie losowej wartości k całkowicie ujawnia private key.
3. RSA (Rivest-Shamir-Adleman):
   • Klasyczny algorytm oparty na faktoryzacji dużych liczb pierwszych.
   • Klucze o długości mniejszej niż 2048 bity są uważane za skompromitowane. Bezpiecznym minimum jest 4096 bitów.
   • Masywny publiczny i prywatny klucz, wolniejsza generacja oraz podpisywanie.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Autentykacja sprzętowa poprzez fizyczne tokeny (YubiKey).
   • Private key jest generowany i nigdy nie opuszcza zabezpieczonego chipu tokenu; każda sesja SSH wymaga fizycznego dotknięcia.

3. Pipeline techniczny i mechanika wewnętrzna

Generowanie i deployment bezpiecznego klucza

Generowanie produkcyjnego klucza Ed25519 ze zwiększoną liczbą rund derivacji klucza (KDF) w celu ochrony przed GPU-brute-force na passphrase:

# Генерація Ed25519 з коментарем та 100 раундами KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Kopiowanie publicznego klucza na zdalny serwer:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Struktura uprawnień systemu plików Linux

Niepoprawne uprawnienia dostępu są przyczyną 90% awarii autentykacji SSH (Permission denied (publickey)):

# Локальна машина клієнта:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Віддалений сервер:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Konfiguracja klienta (~/.ssh/config)

Aby uniknąć przekazywania długich flag linii poleceń, stosuje się declarative client config:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Praktyczne scenariusze inżynierskie w produkcji

01. Bezpasmolowy dostęp dla zautomatyzowanego pipeline CI/CD

W środowiskach GitHub Actions lub GitLab CI/CD deployment odbywa się automatycznie poprzez dedykowany techniczny klucz SSH. Private key jest przechowywany w zaszyfrowanych Secrets repozytorium, a public key na serwerze przypisany do ograniczonego shell lub konkretnej komendy za pomocą dyrektywy command="..." w authorized_keys:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Nawet jeśli secret CI/CD zostanie skompromitowany, napastnik będzie mógł wykonać jedynie deterministyczny script deployujący, a nie dowolne komendy w terminalu.

02. Dostęp do izolowanych węzłów infrastrukturalnych przez Bastion (ProxyJump)

W VPC prywatne bazy danych lub serwery agentów AI nie posiadają publicznych adresów IP. Inżynier łączy się przez pośredni host Bastion bez konieczności eksportowania private key na Bastion:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH tuneluje ruch TCP na poziomie socketu przez węzeł proxy, szyfrując sesję końcowym kluczem docelowego serwera (ProxyJump nie ujawnia zawartości ruchu bastionowi).

03. Sprzętowe klucze FIDO2 dla infrastruktury Zero Trust

W systemach fintech o wysokim obciążeniu lub regulowanych, deweloperzy są zobligowani do używania sprzętowych tokenów YubiKey. Tworzony jest klucz typu ed25519-sk. Każda akcja git push lub sesja SSH wymaga fizycznego naciśnięcia palcem sensora tokenu. Całkowicie niweluje to zagrożenie kradzieży private keys przez infostealery lub złośliwe oprogramowanie na laptopie dewelopera.

5. Pułapki, typowe błędy i bezpieczeństwo

1. Generowanie kluczy bez Passphrase: Zapisanie private key bez silnego hasła tworzy krytyczne zagrożenie: każdy złośliwy proces, skrypt lub fizyczny dostęp do odblokowanego laptopa pozwala natychmiast skopiować private key i uzyskać dostęp do całej infrastruktury. Zawsze chroń klucze hasłem i używaj ssh-agent.
2. Niekontrolowany sprawl w authorized_keys: Z czasem w pliku gromadzą się dziesiątki kluczy byłych deweloperów lub tymczasowych kontraktorów. Brak regularnego audytu otwiera backdoory. Stosuj centralne zarządzanie kluczami poprzez Ansible, Teleport, HashiCorp Vault lub SSH Certificate Authority (CA).
3. Użycie SSH Agent Forwarding (-A): Włączenie ForwardAgent yes w globalnej konfiguracji pozwala zdalnym maszynom uzyskiwać dostęp do Twojego lokalnego socketu ssh-agent. Nigdy nie włączaj Agent Forwarding globalnie; używaj ProxyJump lub ssh-agent -c do potwierdzania każdego użycia klucza.