SSH klíče: jak je vytvořit, jaký typ zvolit a jak vypnout hesla

SSH klíč je dvojice souborů: soukromý klíč zůstává na vašem počítači a veřejný klíč patří na serveru do ~/.ssh/authorized_keys nebo do ovládacího panelu vašeho hostingu. Klíč vytvořte příkazem ssh-keygen -t ed25519, veřejnou část zkopírujte pomocí ssh-copy-id, přihlášení vyzkoušejte v novém okně a teprve potom vypněte přihlašování heslem. Nakonec vždy zkontrolujte skutečně platné nastavení příkazem sshd -T: na našem testovacím serveru soubor 50-cloud-init.conf potichu nechával hesla zapnutá, přestože kontrola syntaxe nehlásila žádnou chybu.

Stručně: od nuly k přihlášení klíčem

Na vlastním počítači (Linux, macOS nebo PowerShell ve Windows 10 a 11, které už klienta OpenSSH obsahují):

ssh-keygen -t ed25519 -C "laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
ssh -i ~/.ssh/id_ed25519 user@server

Druhý příkaz se jednou zeptá na heslo k serveru a odpoví Number of key(s) added: 1. Na testovacím serveru sám vytvořil ~/.ssh s oprávněním 700 a authorized_keys s oprávněním 600. Pokud jste se k serveru přes SSH ještě nikdy nepřipojovali, začněte naším návodem, jak se připojit přes SSH z Windows, macOS a Linuxu.

Ed25519, RSA, nebo ECDSA: co ukázala měření

Vygenerovali jsme klíče všech běžných typů a s každým jsme se na server přihlásili 15krát. Výsledky:

Závěr je jednoduchý: typ klíče rychlost přihlášení neovlivňuje, rozdíly jsou v rámci šumu měření. Čas připojení padne na výměnu klíčů a přípravu relace, ne na jeden podpis. Liší se velikost a pohodlí: veřejný klíč Ed25519 je jeden krátký řádek, který snadno vložíte do panelu nebo do zprávy, kdežto RSA 4096 má 700 znaků a při kopírování se rozbije častěji. Navíc je doba generování RSA náhodná: deset generování RSA 4096 trvalo od 0,7 do 3,2 sekundy.

Praktické pravidlo:

• Ed25519 pro každý nový klíč. Od OpenSSH 9.5 ho ssh-keygen vytváří, když vynecháte -t; na verzi 9.6 jsme to ověřili.
• RSA 3072 nebo 4096 jen tehdy, když server nebo zařízení Ed25519 nepodporuje: velmi starý OpenSSH, některá síťová zařízení, zastaralé knihovny.
• ECDSA funguje, ale pro běžné přihlašování nemá oproti Ed25519 žádnou výhodu.
• Klíče FIDO2 (ed25519-sk) uchovávají tajemství na hardwarovém tokenu a vyžadují dotyk. Bez zařízení se ssh-keygen -t ed25519-sk na testovacím serveru zastavil s hláškou Key enrollment failed: device not found.

Heslová fráze a ssh-agent

Heslová fráze (passphrase) šifruje soukromý klíč na disku: pokud vám soubor ukradnou i s notebookem, bez fráze je k ničemu. Volba -a nastavuje počet kol KDF, tedy jak drahé je frázi uhodnout hrubou silou. Změřili jsme, jak dlouho trvá dešifrování klíče:

• -a 16 (výchozí): 148 ms;
• -a 100: 1,0 s;
• -a 200: 2,0 s.

Sekunda na odemčení je téměř nepostřehnutelná, když agent dešifruje klíč jednou za pracovní den:

ssh-keygen -t ed25519 -a 100 -C "work-laptop"
eval "$(ssh-agent -s)"
ssh-add -t 8h ~/.ssh/id_ed25519
ssh-add -l

Po ssh-add prošla tři přihlášení za sebou bez jediného dotazu. Bez agenta klíč chráněný frází neinteraktivně nefunguje: náš skript dostal Permission denied (publickey,password). Ve Windows je agent služba, kterou jednou zapnete v PowerShellu spuštěném jako správce: Get-Service ssh-agent | Set-Service -StartupType Automatic, potom Start-Service ssh-agent a ssh-add.

Přidání klíče na server, do panelu hostingu a do PuTTY

Pokud ssh-copy-id nemáte (Windows ho neobsahuje), přihlaste se heslem a klíč připište ručně:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... laptop-2026" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Každý klíč musí být přesně na jednom řádku. Když jsme řádek rozdělili na dva, jak se stává při kopírování z úzkého okna, server přihlášení potichu odmítl a v logu bylo jen Failed publickey. Soubor zkontrolujete příkazem ssh-keygen -lf ~/.ssh/authorized_keys: vypíše otisk pro každý platný řádek. Konce řádků z Windows (CRLF) sshd 9.6 přijal bez problémů.

Panel hostingu. V mnoha panelech se SSH klíče přidávají pro jednotlivé uživatele: do nastavení uživatele vložíte řádek ze svého souboru .pub a panel ho připíše do authorized_keys daného uživatele. Přihlášení přes SSH funguje jen tehdy, když má uživatel nebo jeho balíček skutečný shell, a ne nologin. Na sdíleném hostingu o tom rozhoduje poskytovatel, proto se zeptejte podpory, zda je SSH pro váš účet zapnuté. U RichHost je přístup přes SSH součástí všech tarifů.

PuTTY a FileZilla. PuTTY používá vlastní formát .ppk. Převod jsme otestovali v puttygen 0.81:

puttygen ~/.ssh/id_ed25519 -o key.ppk
puttygen key.ppk -O public-openssh
puttygen key.ppk -O private-openssh -o id_from_ppk

Soubor dostal hlavičku PuTTY-User-Key-File-3, plink se s ním přihlásil a otisk odpovídal původnímu klíči. Opačně to nefunguje: se souborem .ppk OpenSSH odpověděl Load key "key.ppk": error in libcrypto. Stejný klíč funguje i pro SFTP; nastavení klienta popisuje návod FileZilla: připojení k hostingu.

~/.ssh/config a “Too many authentication failures”

Abyste nemuseli pokaždé psát port, uživatelské jméno a cestu ke klíči, přidejte záznam do ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    Port 22
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Teď stačí ssh myserver a ssh -G myserver ukáže skutečně použité hodnoty. Řádek IdentitiesOnly yes je důležitý: do agenta jsme nahráli šest nesouvisejících klíčů a připojovali se správným klíčem přes -i. Klient nejdřív zkoušel klíče z agenta a server s výchozím MaxAuthTries 6 spojení ukončil hláškou Too many authentication failures. S IdentitiesOnly yes přihlášení prošlo hned. I samotný konfigurační soubor musí být soukromý: s oprávněním 666 klient odmítl pracovat (Bad owner or permissions).

Oprávnění: co sshd myslí hláškou “bad ownership or modes”

StrictModes yes (výchozí) způsobí, že sshd klíč ignoruje, pokud by soubory mohli měnit jiní uživatelé. Klient vidí jen Permission denied (publickey); důvod je v logu serveru. Co jsme dostali:

Specialita Ubuntu a Debianu: sshd přijal oprávnění 664 u authorized_keys a 775 u domovského adresáře, protože skupinou byla soukromá skupina uživatele. Jakmile byl soubor přiřazen jiné skupině se stejným oprávněním 664, přihlášení se zablokovalo. Jednoduché pravidlo: ~/.ssh 700, soubory uvnitř 600, vlastníkem jste vy. Klient je ještě přísnější: soukromý klíč s oprávněním 644 ignoruje a vypíše UNPROTECTED PRIVATE KEY FILE.

Vypnutí přihlašování heslem a kontrola přes sshd -T

Nechte současnou relaci otevřenou, dokud přihlášení klíčem nebude fungovat v novém okně. Nastavení uložte do samostatného souboru, jehož název se seřadí před ostatní:

# /etc/ssh/sshd_config.d/01-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
sudo systemctl reload ssh

V Ubuntu a Debianu se služba jmenuje ssh, v systémech typu RHEL sshd. Proč samostatný soubor s předponou 01: sshd použije první nalezenou hodnotu nastavení a řádek Include je na začátku hlavní konfigurace. Na testovacím serveru jsme zopakovali tři pasti:

1. 50-cloud-init.conf s PasswordAuthentication yes (cloud-init ho vytváří na mnoha cloudových obrazech) a k tomu náš vlastní 99-hardening.conf: sshd -t nehlásil chyby, sshd -T ukázal passwordauthentication yes a přihlášení heslem prošlo.
2. PasswordAuthentication no připsané na konec hlavního sshd_config, jak radí mnoho starších návodů: stejný výsledek, hesla dál fungovala.
3. PasswordAuthentication no, ale KbdInteractiveAuthentication yes spolu s UsePAM yes: server metodu password odmítl, stejné heslo ale přijal přes keyboard-interactive a do logu zapsal Accepted keyboard-interactive/pam.

Soubor 01-hardening.conf vyřešil všechny tři případy. Pokud vaše konfigurace obsahuje bloky Match, otestujte konkrétní připojení: u nás sshd -T vypsal no, zatímco sshd -T -C user=deploy,host=x,addr=127.0.0.1 vypsal yes pro adresu, na kterou se vztahoval Match Address. Kompletní kontrolní seznam první hodiny na novém serveru najdete v návodu nastavení VPS s Ubuntu.

Chyby SSH klíčů: příčina a řešení

Co dělat ve vaší situaci

U tarifů sdíleného hostingu RichHost spravujete weby ve vlastním ovládacím panelu s asistentem AI a podpora pomáhá s dotazy k přístupu od 10:00 do 20:00 kyjevského času.

Časté otázky

Mohu používat jeden klíč pro všechny servery?

Technicky ano, lepší je ale jeden klíč pro každé zařízení, ze kterého se přihlašujete. Ztracený notebook pak znamená smazat jeden řádek z authorized_keys, ne měnit klíč všude.

Kde je soukromý klíč a mohu ho dát kolegovi?

V ~/.ssh (ve Windows C:\Users\name\.ssh). Nikdy ho nesdílejte: kolega si vytvoří vlastní pár klíčů a vy přidáte jeho veřejný klíč na server.

Vypnul jsem hesla a ztratil klíč. Co teď?

Přihlaste se přes webovou konzoli nebo KVM v panelu poskytovatele, přidejte nový veřejný klíč a znovu načtěte sshd. Na sdíleném hostingu můžete klíč znovu přidat v panelu nebo požádat o pomoc podporu.

Mám změnit port 22?

Sníží to šum v logu, ale ochrana to není. Skutečnou ochranu dává přihlašování pouze klíčem s vypnutými hesly, ověřené přes sshd -T.