SSH: Kompletny Przewodnik Techniczny po Bezpiecznym Zdalnym Zarządzaniu Serwerem

SSH (Secure Shell) jest kryptograficznym protokołem sieciowym, który ustanawia zaszyfrowany tunel między dwoma hostami w sieci, umożliwiając uwierzytelnione wykonywanie poleceń, transfer plików i przekierowanie portów przez niezaufane sieci. Domyślnie działa na porcie TCP 22 i zastępuje poprzedniki używające tekstu jawnego — Telnet, rsh i FTP — protokołem zapewniającym poufność, integralność i wzajemne uwierzytelnianie w ramach jednego uzgadniania.

Dla każdego administratora zarządzającego VPS lub serwerem dedykowanym, SSH nie jest opcjonalną infrastrukturą — jest to podstawowa płaszczyzna sterowania. Każda decyzja konfiguracyjna dotycząca SSH bezpośrednio wpływa na powierzchnię ataku serwera, niezawodność operacyjną i zgodność z przepisami.

Jak działa SSH: Architektura protokołu

Zrozumienie SSH na poziomie protokołu odróżnia administratorów, którzy konfigurują go poprawnie, od tych, którzy pozostawiają luki możliwe do wykorzystania.

Model trzywarstwowy

SSH jest zdefiniowany przez RFC 4251–4254 i działa w trzech odrębnych podwarstwach ułożonych na szczycie TCP:

• Protokół warstwy transportowej SSH — obsługuje uwierzytelnianie serwera, wymianę kluczy, negocjację szyfrowania i konfigurację MAC (kodu uwierzytelniania wiadomości). Tutaj odbywa się kryptograficzne uzgadnianie.
• Protokół uwierzytelniania użytkownika SSH — działa na szczycie warstwy transportowej i obsługuje uwierzytelnianie klient-serwer przy użyciu metod takich jak publickey, password, keyboard-interactive lub gssapi-with-mic.
• Protokół połączenia SSH — multipleksuje zaszyfrowany tunel na logiczne kanały, z których każdy przenosi sesję powłoki, podsystem SFTP, przekierowany port lub połączenie agenta.

Szczegółowy przebieg uzgadniania

Po uruchomieniu ssh user@host przed wyświetleniem znaku zachęty wykonywana jest następująca sekwencja:

1. Połączenie TCP jest nawiązywane z serwerem na skonfigurowanym porcie.
2. Wymiana wersji — klient i serwer wymieniają ciągi wersji protokołu (SSH-2.0-OpenSSH_9.x).
3. Negocjacja algorytmów (SSH_MSG_KEXINIT) — obie strony ogłaszają obsługiwane algorytmy wymiany kluczy, typy kluczy hosta, szyfry, MAC-i i metody kompresji. Wygrywa pierwsza wzajemnie obsługiwana opcja z każdej listy.
4. Wymiana kluczy (KEX) — zazwyczaj Diffie-Hellman lub Elliptic Curve Diffie-Hellman (ECDH). Obie strony wyprowadzają wspólny sekret bez jego przesyłania. Generuje to klucze sesji.
5. Weryfikacja klucza hosta serwera — serwer podpisuje wartość swoim prywatnym kluczem hosta. Klient sprawdza ten podpis w pliku ~/.ssh/known_hosts. Niezgodność wywołuje ostrzeżenie i domyślnie blokuje połączenie.
6. Aktywacja szyfrowania — cały kolejny ruch jest szyfrowany i chroniony pod względem integralności przy użyciu wynegocjowanego szyfru (np. chacha20-poly1305) i MAC.
7. Uwierzytelnianie użytkownika — klient próbuje uwierzytelnienia przy użyciu wynegocjowanej metody. W przypadku uwierzytelniania publickey klient podpisuje wyzwanie swoim kluczem prywatnym; serwer weryfikuje to przy użyciu przechowywanego klucza publicznego.
8. Otwarcie kanału — otwierany jest kanał powłoki, podsystemu SFTP lub exec i rozpoczyna się sesja.

Cały ten proces zazwyczaj kończy się w czasie poniżej 100 milisekund w sieci lokalnej.

Kryptografia symetryczna a asymetryczna w SSH

Powszechnym błędnym przekonaniem jest to, że SSH „używa szyfrowania kluczem publicznym” dla całego ruchu. Tak nie jest. Role są odrębne:

SSH a starsze protokoły zdalnego dostępu

Generowanie par kluczy SSH

Pary kluczy SSH stanowią podstawę bezpiecznego i skalowalnego dostępu do serwera. Uwierzytelnianie hasłem jest podatne na ataki brute-force i upychanie danych uwierzytelniających; uwierzytelnianie oparte na kluczach nie jest.

Wybór właściwego algorytmu klucza

Ed25519 jest aktualnie najlepszą praktyką. Używa kryptografii krzywej eliptycznej Curve25519, generuje kompaktowe klucze 256-bitowe, jest szybszy niż RSA przy równoważnych poziomach bezpieczeństwa i jest obsługiwany przez OpenSSH 6.5+ (wydany w 2014 roku).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Używaj RSA tylko wtedy, gdy potrzebujesz zgodności ze starszymi systemami, które nie obsługują Ed25519:

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

Nie używaj DSA (ograniczonego do 1024 bitów, złamanego) ani ECDSA z krzywymi NIST (obawy dotyczące pochodzenia parametrów krzywych NIST). Ed25519 jest jednoznacznym wyborem dla nowych wdrożeń.

Przewodnik po generowaniu kluczy

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Zostaniesz poproszony o:

• Lokalizację pliku — domyślnie ~/.ssh/id_ed25519. Zaakceptuj wartość domyślną lub podaj niestandardową ścieżkę dla środowisk z wieloma kluczami.
• Hasło — zawsze je ustaw. Hasło szyfruje klucz prywatny w spoczynku przy użyciu AES-256-CBC (lub bcrypt w nowszym OpenSSH). Jeśli plik klucza prywatnego zostanie skradziony, hasło jest ostatnią linią obrony.

Generuje to dwa pliki:

~/.ssh/id_ed25519 — klucz prywatny. Nigdy go nie udostępniaj. Uprawnienia muszą wynosić 600.
~/.ssh/id_ed25519.pub — klucz publiczny. To właśnie ten plik dystrybuujesz na serwery.

Zarządzanie wieloma kluczami za pomocą ~/.ssh/config
Podczas zarządzania wieloma serwerami lub kontami użyj pliku konfiguracyjnego SSH, aby uniknąć podawania flag przy każdym połączeniu:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Po wprowadzeniu tej konfiguracji ssh prod-web automatycznie rozszerza się do pełnych parametrów połączenia.
Wdrażanie klucza publicznego na serwerze
Metoda 1: ssh-copy-id (zalecana przy początkowej konfiguracji)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Powoduje to dołączenie klucza publicznego do ~/.ssh/authorized_keys na zdalnym hoście i automatyczne ustawienie prawidłowych uprawnień.
Metoda 2: Ręczne wdrożenie (gdy ssh-copy-id jest niedostępne)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Metoda 3: Konsola dostawcy chmury lub API
Większość dostawców chmury i paneli sterowania hostingiem umożliwia wstrzykiwanie kluczy publicznych podczas inicjowania instancji. Jest to właściwe podejście dla zautomatyzowanej infrastruktury — klucz jest obecny przed uruchomieniem instancji, co eliminuje problem jajka i kury polegający na konieczności użycia SSH do wdrożenia kluczy SSH.
Format pliku authorized_keys
Każda linia w ~/.ssh/authorized_keys to jeden klucz publiczny, opcjonalnie poprzedzony opcjami:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
Opcja restrict wyłącza przekierowanie portów, przekierowanie agenta i alokację PTY dla tego klucza — przydatne dla kluczy wdrożeniowych lub kont automatyzacji kopii zapasowych, które nie powinny mieć interaktywnego dostępu do powłoki.
Wzmacnianie serwera SSH: /etc/ssh/sshd_config
Domyślna instalacja OpenSSH jest funkcjonalna, ale nie wzmocniona. Poniższa konfiguracja stanowi bazę na poziomie produkcyjnym. Zastosuj zmiany w /etc/ssh/sshd_config, a następnie zweryfikuj i przeładuj:
sshd -t && systemctl reload sshd
Zawsze uruchamiaj sshd -t przed przeładowaniem — błąd składni w sshd_config nie spowoduje awarii działającego demona, ale uniemożliwi jego ponowne uruchomienie po restarcie, blokując dostęp.
Zalecany blok wzmacniający sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Wyjaśnienie kluczowych decyzji dotyczących wzmacniania
PermitRootLogin no — Logowanie roota przez SSH jest wartościowym celem ataku. Używaj zwykłego użytkownika i eskaluj uprawnienia za pomocą sudo. Jeśli absolutnie potrzebujesz dostępu równoważnego rootowi przez określony klucz (np. do automatyzacji), użyj PermitRootLogin prohibit-password, aby zezwolić na logowanie roota tylko kluczem, blokując jednocześnie próby hasłem.
AllowTcpForwarding no — Jeśli Twój serwer nie jest hostem bastion ani hostem przeskoku, wyłącz przekierowanie TCP. W przeciwnym razie atakujący z prawidłową sesją SSH mógłby używać Twojego serwera jako proxy do uzyskiwania dostępu do zasobów sieci wewnętrznej.
TCPKeepAlive no z ClientAliveInterval — TCPKeepAlive działa na warstwie TCP i jest widoczny dla pośredników sieciowych. ClientAliveInterval wysyła komunikaty keepalive przez zaszyfrowany kanał SSH, co jest zarówno bardziej niezawodne, jak i bardziej prywatne.
LoginGraceTime 30 — Skraca okno czasowe, w którym nieuwierzytelnione połączenie zajmuje slot serwera. Domyślna wartość 120 sekund jest nadmierna.
AllowUsers — Umieszczaj na białej liście tylko konta, które faktycznie potrzebują dostępu SSH. Jest to twarda brama działająca przed jakąkolwiek próbą uwierzytelnienia.
Zmiana domyślnego portu SSH
Przeniesienie SSH z portu 22 nie poprawia bezpieczeństwa przed ukierunkowanym atakującym — każde skanowanie portów go znajdzie. Co jednak robi, to eliminuje ogromną liczbę zautomatyzowanych, oportunistycznych botów brute-force, które atakują wyłącznie port 22. Znacząco zmniejsza to szum w logach i obciążenie serwera.
# In /etc/ssh/sshd_config
Port 2222
Przed przeładowaniem otwórz nowy port w zaporze:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Jeśli Twój serwer używa SELinux, musisz również zaktualizować kontekst portu SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Łączenie się z serwerem
Podstawowe połączenie
ssh user@your_server_ip
Łączenie się z niestandardowym portem
ssh -p 2222 user@your_server_ip
Łączenie się z określonym kluczem
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Tryb szczegółowy do debugowania
ssh -vvv user@your_server_ip
Flaga -vvv wyświetla każdy krok uzgadniania, próby uwierzytelnienia i negocjacji kanału. Jest to pierwsze narzędzie, po które należy sięgnąć, gdy połączenie nieoczekiwanie się nie powiedzie.
Bezpieczny transfer plików przez SSH
SCP (Secure Copy Protocol)
SCP to proste, nieinteraktywne narzędzie do kopiowania plików. Jest szybkie i powszechnie dostępne, ale nie ma możliwości wznawiania i ograniczonej obsługi błędów.
Kopiowanie lokalnego pliku na zdalny serwer:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Kopiowanie zdalnego pliku lokalnie:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Rekurencyjne kopiowanie katalogu:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Uwaga: Projekt OpenSSH wycofał starszy protokół SCP w OpenSSH 9.0. Nowoczesne scp domyślnie używa teraz protokołu SFTP pod spodem. Interfejs poleceń pozostaje taki sam, ale podstawowy transport jest bardziej niezawodny.
SFTP (SSH File Transfer Protocol)
SFTP to w pełni funkcjonalny podsystem transferu plików z listowaniem katalogów, zarządzaniem uprawnieniami i obsługą wznawiania. Jest to właściwy wybór do interaktywnego zarządzania plikami.
sftp -P 2222 user@your_server_ip
Typowe polecenia SFTP w sesji interaktywnej:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync przez SSH (zalecenie produkcyjne)
Do synchronizacji katalogów, przyrostowych kopii zapasowych lub dużych zbiorów danych, rsync przez SSH jest znacznie wydajniejszy niż SCP lub SFTP. Przesyła tylko zmienione bloki, a nie całe pliki.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
Flaga -z włącza kompresję podczas przesyłania. W przypadku już skompresowanych danych (archiwów, obrazów) pomiń ją — kompresja skompresowanych danych marnuje CPU bez zmniejszania rozmiaru transferu.
Przekierowanie portów SSH i tunelowanie
Przekierowanie portów jest jedną z najpotężniejszych i najrzadziej używanych możliwości SSH. Pozwala na bezpieczny dostęp do usług, które nie są bezpośrednio wystawione na internet.
Lokalne przekierowanie portów
Przekierowanie lokalnego portu do zdalnej usługi. Przykład: dostęp do zdalnej instancji MySQL (port 3306) powiązanej z localhost na serwerze:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Teraz mysql -h 127.0.0.1 -P 3307 na Twoim lokalnym komputerze łączy się przez zaszyfrowany tunel ze zdalnym MySQL.
Zdalne przekierowanie portów
Udostępnianie lokalnej usługi zdalnemu serwerowi. Przydatne do testowania webhooków lub udostępniania lokalnego serwera deweloperskiego:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Dynamiczne przekierowanie portów (proxy SOCKS)
Przekształcenie połączenia SSH w proxy SOCKS5, kierując dowolny ruch TCP przez serwer:
ssh -D 1080 user@your_server_ip -N
Skonfiguruj przeglądarkę lub aplikację do używania SOCKS5 127.0.0.1:1080.
Agent SSH i przekierowanie agenta
ssh-agent przechowuje odszyfrowane klucze prywatne w pamięci, dzięki czemu nie musisz ponownie wprowadzać hasła przy każdym połączeniu.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Przekierowanie agenta (ssh -A) pozwala zdalnemu serwerowi używać Twojego lokalnego agenta do uwierzytelniania na trzecim serwerze. Jest to przydatne w architekturach z hostem bastion, ale niesie ze sobą ryzyko: użytkownik root na serwerze pośrednim może używać Twojego przekierowanego gniazda agenta. Zamiast tego preferuj ProxyJump:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump kieruje połączenie TCP przez bastion bez ujawniania mu Twojego agenta.
Rozwiązywanie typowych problemów SSH
Odmowa połączenia (ssh: connect to host ... port 22: Connection refused)
Systematyczna diagnoza:

Sprawdź, czy demon SSH działa: systemctl status sshd

• Potwierdź nasłuchiwany port: ss -tlnp | grep sshd
• Sprawdź reguły zapory: ufw status lub iptables -L -n | grep 22
• Sprawdź, czy serwer jest osiągalny na poziomie sieci: ping your_server_ip
• Jeśli używasz dostawcy chmury, sprawdź reguły grupy zabezpieczeń lub listy ACL sieci w konsoli dostawcy.

Odmowa dostępu (publickey)

Jest to najczęstszy błąd SSH. Przejdź przez tę listę kontrolną:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Typowe przyczyny poza uprawnieniami:

• Plik authorized_keys zawiera niewłaściwy klucz (np. skopiowałeś klucz prywatny zamiast pliku .pub).

StrictModes yes w sshd_config (domyślnie) odrzuca połączenia, jeśli uprawnienia katalogu domowego są zbyt otwarte — chmod 755 ~ to maksimum dozwolone.
AllowUsers lub AllowGroups w sshd_config wyklucza łączącego się użytkownika.
SELinux blokuje dostęp do ~/.ssh/ — sprawdź ausearch -m avc -ts recent.

Przekroczenie limitu czasu połączenia SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval wysyła pusty pakiet przez zaszyfrowany kanał co 60 sekund. Po ClientAliveCountMax kolejnych nieodebranych odpowiedziach serwer kończy połączenie. Zapobiega to gromadzeniu się sesji zombie.
Weryfikacja klucza hosta nie powiodła się
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
To ostrzeżenie oznacza, że klucz hosta serwera nie pasuje już do tego, co jest przechowywane w ~/.ssh/known_hosts. Uzasadnione przyczyny obejmują ponowną instalację serwera lub zmianę przypisania adresu IP. Złośliwe przyczyny obejmują atak man-in-the-middle. Zbadaj sprawę przed kontynuowaniem.
Jeśli potwierdziłeś, że serwer został legalnie ponownie zainstalowany:
ssh-keygen -R your_server_ip
Następnie połącz się ponownie i zweryfikuj odcisk palca nowego klucza hosta w konsoli serwera lub panelu dostawcy przed jego zaakceptowaniem.
Uwierzytelnianie wieloskładnikowe dla SSH
Uwierzytelnianie oparte na kluczach jest silne, ale dodanie drugiego czynnika TOTP (Time-based One-Time Password) tworzy obronę w głąb. Nawet jeśli klucz prywatny i jego hasło zostaną skompromitowane, atakujący nie może uwierzytelnić się bez tokenu TOTP.
Zainstaluj i skonfiguruj libpam-google-authenticator na serwerze:
apt install libpam-google-authenticator
google-authenticator
Następnie skonfiguruj PAM i sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Dzięki AuthenticationMethods publickey,keyboard-interactive użytkownik musi podać prawidłowy klucz ORAZ kod TOTP. Jest to właściwa konfiguracja produkcyjna dla serwerów o wysokiej wartości.
Urząd certyfikacji SSH: Skalowanie zarządzania kluczami
W środowiskach z dziesiątkami serwerów i wieloma administratorami zarządzanie indywidualnymi wpisami authorized_keys staje się operacyjnie niemożliwe do utrzymania. Certyfikaty SSH rozwiązują ten problem.
Urząd certyfikacji SSH (CA) podpisuje klucze użytkowników i hostów. Serwery ufają kluczowi publicznemu CA, a nie indywidualnym kluczom użytkowników. Dodanie nowego administratora wymaga jedynie podpisania jego klucza publicznego — bez zmian w pliku authorized_keys żadnego serwera.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
Na każdym serwerze skonfiguruj zaufanie do CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
W ten sposób infrastruktura na dużą skalę (w tym dostawcy chmury i przedsiębiorstwa) zarządza dostępem SSH bez zarządzania kluczami na poziomie poszczególnych serwerów.
Praktyczna macierz decyzyjna: Konfiguracja SSH według przypadku użycia



Przypadek użycia
Typ klucza
Port
Uwierzytelnianie hasłem
Logowanie roota
Przekierowanie
MFA








—
—
—
—
—
—
—








Osobisty VPS
Ed25519
2222+
Wyłączone
Zabronione
Wyłączone
Opcjonalne








Produkcyjny serwer WWW
Ed25519
Niestandardowy
Wyłączone
Nie
Wyłączone
Wymagane








Bastion / host przeskoku
Ed25519
22 lub niestandardowy
Wyłączone
Nie
Kontrolowane
Wymagane








Automatyzacja CI/CD
Ed25519 (klucz wdrożeniowy)
Niestandardowy
Wyłączone
Nie
Wyłączone
Nie (tylko klucz)








Serwer bazy danych
Ed25519
Niestandardowy
Wyłączone
Nie
Tylko lokalne
Wymagane








Serwer deweloperski
Ed25519
Domyślny lub niestandardowy
Opcjonalne
Nie
Opcjonalne
Opcjonalne





Konfigurowanie SSH w infrastrukturze AlexHost
Gdy inicjujesz VPS lub serwer dedykowany przez AlexHost, dostęp SSH jest domyślnie skonfigurowany. Początkowe hasło roota jest dostarczane przez e-mail inicjujący, a zalecanym pierwszym działaniem jest:

Zalogowanie się jako root, utworzenie nieuprzywilejowanego użytkownika administracyjnego i dodanie klucza publicznego do ~/.ssh/authorized_keys tego użytkownika.
Zastosowanie bazy wzmacniającej sshd_config udokumentowanej powyżej.
Wyłączenie uwierzytelniania hasłem i logowania roota.
Skonfigurowanie zapory w celu ograniczenia dostępu SSH do znanych zakresów IP, tam gdzie jest to operacyjnie możliwe.

Jeśli preferujesz graficzną warstwę zarządzania obok SSH, opcje VPS z cPanel i paneli sterowania VPS AlexHost zapewniają interfejs WWW dla typowych zadań, pozostawiając SSH dostępnym dla pełnej kontroli administracyjnej.
W środowiskach, w których musisz zabezpieczyć aplikacje WWW działające na tym samym serwerze, połączenie wzmacniania SSH z prawidłowo skonfigurowanym certyfikatem SSL obejmuje zarówno administracyjne, jak i aplikacyjne warstwy transportowe.
Lista kontrolna kluczowych wniosków technicznych
Przed uznaniem konfiguracji SSH za gotową do produkcji zweryfikuj każdy z poniższych punktów:
Zarządzanie kluczami

Klucze prywatne używają Ed25519 lub minimum RSA-4096
Wszystkie klucze prywatne są chronione silnym hasłem
Katalog ~/.ssh/ ma uprawnienia 700; authorized_keys ma 600

• Klucze wdrożeniowe używają opcji restrict i command= tam, gdzie ma to zastosowanie
• Harmonogram rotacji kluczy jest udokumentowany i egzekwowany

Konfiguracja serwera

PasswordAuthentication no jest ustawione i aktywne
PermitRootLogin no lub prohibit-password jest egzekwowane
SSH działa na niestandardowym porcie z zaktualizowanymi regułami zapory
AllowUsers lub AllowGroups ogranicza dostęp do nazwanych kont
LoginGraceTime jest ustawione na 30 sekund lub mniej
sshd -t przechodzi bez błędów po każdej zmianie konfiguracji

Wzmacnianie kryptograficzne

KexAlgorithms wyklucza diffie-hellman-group1-sha1 i diffie-hellman-group14-sha1

• Ciphers wyklucza 3des-cbc, arcfour i blowfish-cbc
• MACs używa wyłącznie wariantów -etm (encrypt-then-MAC)

Bezpieczeństwo operacyjne

• Logi uwierzytelniania SSH są monitorowane (/var/log/auth.log lub journalctl -u sshd)
• fail2ban lub odpowiednik jest skonfigurowany do blokowania powtarzających się błędów uwierzytelnienia
• Odciski palców kluczy hosta są rejestrowane i przechowywane poza pasmem do weryfikacji
• MFA jest włączone dla wszystkich interaktywnych sesji użytkowników na systemach produkcyjnych
• SSH CA jest używane w środowiskach z więcej niż pięcioma serwerami lub trzema administratorami

FAQ

Jaka jest różnica między kluczami SSH a certyfikatami SSH?

Klucze SSH wymagają, aby każdy serwer przechowywał klucz publiczny użytkownika w authorized_keys. Certyfikaty SSH są podpisywane przez Urząd Certyfikacji; serwery ufają CA, a nie indywidualnym kluczom. Certyfikaty skalują się do dużych flot bez zarządzania kluczami na poziomie poszczególnych serwerów i obsługują czasy wygaśnięcia, co ułatwia unieważnianie.

Dlaczego Permission denied (publickey) pojawia się nawet gdy klucz jest prawidłowy?

Najczęstsze przyczyny to nieprawidłowe uprawnienia pliku ~/.ssh/ (muszą wynosić 700) lub authorized_keys (muszą wynosić 600), katalog domowy z uprawnieniami do zapisu dla wszystkich (blokowany przez StrictModes) lub dyrektywa AllowUsers w sshd_config wykluczająca łączące się konto. Sprawdź journalctl -u sshd na serwerze, aby uzyskać konkretny powód odrzucenia.

Czy zmiana portu SSH z 22 jest prawdziwym środkiem bezpieczeństwa?

Eliminuje zautomatyzowane oportunistyczne ataki skierowane na port 22, co znacząco zmniejsza szum w logach i nieudane próby uwierzytelnienia. Nie chroni przed ukierunkowanym atakującym, który wykonuje skanowanie portów. Powinno być połączone z fail2ban, uwierzytelnianiem tylko kluczem i listą dozwolonych adresów IP w zaporze dla znaczącej poprawy bezpieczeństwa.

Czy mogę używać SSH bez statycznego adresu IP po stronie klienta?

Tak. Uwierzytelnianie oparte na kluczach nie wymaga stałego IP klienta. Jeśli chcesz ograniczyć dostęp według IP, użyj opcji from= w authorized_keys lub reguł zapory. W przypadku dynamicznych adresów IP rozważ użycie VPN w celu ustanowienia stabilnej tożsamości sieciowej przed połączeniem, zamiast otwierania SSH dla całego internetu.

Jaki jest najbezpieczniejszy sposób odzyskania dostępu SSH po zablokowaniu?

Uzyskaj dostęp do serwera przez konsolę out-of-band dostawcy hostingu (VNC, IPMI lub KVM over IP). Stamtąd zamontuj system plików, popraw problem z sshd_config lub authorized_keys i uruchom ponownie demon SSH. W planach VPS i serwera dedykowanego AlexHost konsola dostawcy jest dostępna przez portal klienta i nie zależy od działania SSH.