SSH klíče a zabezpečení SSH serveru krok za krokem

SSH je hlavní vstupní brána na váš server. Přihlašování heslem je pohodlné, ale láká roboty, kteří zkouší tisíce kombinací denně. SSH klíče jsou bezpečnější i pohodlnější – po nastavení se přihlásíte bez psaní hesla. V tomto návodu projdeme celý postup od vygenerování klíče až po ladění chyb.

Jak SSH klíče fungují

Klíč má dvě části:

privátní klíč (~/.ssh/id_ed25519) – zůstává jen na vašem počítači, nikdy ho nikam nekopírujte,
veřejný klíč (~/.ssh/id_ed25519.pub) – nahrajete ho na server do ~/.ssh/authorized_keys.

Server při přihlášení ověří, že vlastníte privátní klíč odpovídající některému z uložených veřejných klíčů.

Vygenerování klíče

Doporučený typ je dnes Ed25519 – krátký, rychlý a bezpečný:

ssh-keygen -t ed25519 -C "jan@notebook-2026"

Program se zeptá na umístění (Enter = výchozí) a na passphrase. Passphrase šifruje privátní klíč na disku – pokud vám někdo ukradne notebook, klíč sám nepoužije. Doporučujeme ji vyplnit a kombinovat s ssh-agent, aby ji nebylo nutné psát pořád.

Pokud se potřebujete připojit k velmi starému systému bez podpory Ed25519, použijte RSA s dostatečnou délkou: ssh-keygen -t rsa -b 4096.

Nahrání klíče na server

Nejjednodušší cesta je ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Na Windows (PowerShell) ssh-copy-id není, použijte:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Pak otestujte přihlášení: ssh [email protected]. Pokud se neptá na heslo serveru (případně jen na passphrase klíče), funguje to.

Vypnutí přihlašování heslem

Až máte jistotu, že klíč funguje, upravte konfiguraci SSH serveru. Na Ubuntu a Debianu vytvořte soubor /etc/ssh/sshd_config.d/99-hardening.conf:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers jan

AllowUsers omezí přihlášení jen na vyjmenované účty.
PermitRootLogin no zakáže přímý login roota; pokud ho potřebujete pro automatizaci, použijte prohibit-password (root jen s klíčem).

Ověřte konfiguraci a načtěte ji:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E 'passwordauth|permitroot|allowusers'

Druhé SSH okno nechte otevřené, dokud nové přihlášení neotestujete.

Má smysl měnit port 22?

Změna portu (např. Port 2222) nesníží skutečné riziko, ale výrazně omezí šum v logech od automatických skenerů. Pokud port měníte, nezapomeňte ho nejdřív povolit ve firewallu (sudo ufw allow 2222/tcp). Na Ubuntu 24.04 navíc SSH používá socket activation (ssh.socket), takže po změně portu spusťte:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Skutečnou ochranu ale přináší vypnutá hesla a nástroj jako fail2ban.

Soubor ~/.ssh/config: konec dlouhých příkazů

Na svém počítači si vytvořte ~/.ssh/config:

Host web01
    HostName 203.0.113.10
    User jan
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Host db01
    HostName 10.0.0.5
    User jan
    ProxyJump web01

Teď stačí ssh web01. Direktiva ProxyJump vás na db01 dostane přes web01, aniž by databázový server musel být dostupný z internetu. Stejné aliasy fungují i pro scp, rsync a VS Code Remote-SSH.

ssh-agent: passphrase jen jednou

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

Na macOS přidejte do ~/.ssh/config řádky AddKeysToAgent yes a UseKeychain yes. Na Windows lze zapnout službu „OpenSSH Authentication Agent“.

Řešení: Permission denied (publickey)

Nejčastější příčiny:

Špatná oprávnění na serveru. SSH ignoruje klíče, pokud jsou soubory přístupné ostatním: bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod go-w ~
Špatný vlastník – soubor patří rootovi místo uživateli: sudo chown -R jan:jan /home/jan/.ssh.
Klient nabízí jiný klíč. Spusťte podrobný výpis: bash ssh -v web01 Hledejte řádky Offering public key a Authentications that can continue.
Log na serveru napoví nejvíc: sudo journalctl -u ssh -n 50.

Shrnutí

Krok	Proč
Ed25519 klíč s passphrase	silná a chráněná identita
`PasswordAuthentication no`	konec útoků hrubou silou
`PermitRootLogin no` + `AllowUsers`	menší plocha útoku
`~/.ssh/config`	pohodlí a méně chyb

Pokud připojujete server do ColdHost AI přes SSH, i tam doporučujeme samostatný klíč a uživatele se sudo, ne přímý přístup roota.