Slovník pojmů

SSH

Secure Shell umožňuje bezpečně spravovat vzdálený server, spustit na něm konkrétní příkaz nebo přes šifrované spojení přenést další síťový provoz. Bezpečnost ale závisí také na ověření host key, správě uživatelských klíčů a omezení oprávnění.

Stručná definice

Zabezpečený protokol pro vzdálené služby, ne jen vzdálený terminál

SSH propojuje klienta a server přes šifrovaný a integritně chráněný transport. Typickým cílem je Linuxový server, na kterém klient otevře interaktivní shell, spustí jeden příkaz nebo použije forwarding. Příkazový řádek, shell a terminál jsou však samostatné pojmy: SSH je může vzdáleně zpřístupnit, ale samo není shellem ani terminálovou aplikací.

Klient a server si při navázání spojení nejdřív sjednají kryptografické parametry a vytvoří klíče relace. Server se prokáže host key a uživatel se autentizuje samostatným mechanismem. Toto rozdělení je důležité: uživatelský veřejný klíč nešifruje celou komunikaci a host key neurčuje, který uživatelský účet smí pracovat se serverem.

Jaký problém řeší

Správu vzdáleného systému přes nedůvěryhodnou síť

SSH nahrazuje nezabezpečené vzdálené přihlášení protokolem, který chrání důvěrnost a integritu komunikace a ověřuje protistrany. Jedno spojení může přenášet více logických kanálů, takže není omezené na jeden interaktivní shell nebo jediný síťový port.

přihlášení správce nebo vývojáře k diagnostice aplikace a systémových služeb
spuštění jednoho vzdáleného příkazu ze skriptu nebo řízeného deploymentu
přenos souborů pomocí SFTP nebo nástroje scp bez samostatného nezabezpečeného protokolu
lokální, vzdálené či dynamické přesměrování vybraného TCP provozu
přístup přes jump host do sítě, která není dostupná přímo z vývojářského počítače

Praktický příklad

Kontrola PHP služby a lokální tunel k databázi

Vývojář se nejprve přihlásí účtem s omezenými oprávněními. Druhý příkaz bez interaktivního shellu pouze vypíše stav PHP-FPM a vrátí jeho exit code. Přesný název služby závisí na distribuci a nainstalované verzi PHP.

Třetí příkaz otevře na klientovi port 15432 jen na loopback adrese a provoz přes SSH předá k portu 5432 dostupnému ze serveru. Databázi tím není potřeba zveřejnit do internetu. Pro delší interaktivní diagnostiku lze po přihlášení použít tmux, aby rozpracovaná terminálová relace nezanikla při krátkém výpadku klienta.

Shell

ssh deploy@app.example.cz
ssh deploy@app.example.cz 'systemctl --no-pager status php8.4-fpm'
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15432:127.0.0.1:5432 deploy@app.example.cz

Jak funguje

Od cílového serveru k zabezpečenému kanálu

Textový diagram: SSH klient → výměna klíčů a ověření host key → šifrovaný transport → autentizace uživatele → shell, příkaz nebo forwarding. Jednotlivé vrstvy spolupracují, ale každá ověřuje jinou část spojení.

Cíl a transport Klient se připojí k hostname nebo IP adrese a TCP portu SSH serveru. Port 22 je běžný výchozí port, nikoli bezpečnostní záruka.
Výměna klíčů Klient a server sjednají algoritmy a odvodí dočasné klíče relace, kterými se chrání důvěrnost a integrita další komunikace.
Ověření serveru Server předloží veřejnou část host key. Klient její fingerprint nebo vazbu na host ověří a přijatý klíč obvykle eviduje v known_hosts pro další spojení.
Autentizace uživatele Server může podle své politiky přijmout například veřejný klíč, heslo, keyboard-interactive výzvu nebo kombinaci metod.
Kanály spojení Po přihlášení se otevře interaktivní shell, vzdálený příkaz, SFTP subsystém nebo povolený forwarding. Server může tyto možnosti omezit pro účet i konkrétní klíč.

Hlavní části a koncepty

Host key, uživatelský klíč a klíč relace mají rozdílné role

Přesné rozlišení klíčů brání nebezpečnému dojmu, že samotná přítomnost souboru s privátním klíčem vyřešila celé zabezpečení.

SSH klient a server

Program ssh zahajuje spojení, zatímco démon sshd na cílovém stroji přijímá spojení a uplatňuje serverovou politiku. OpenSSH je rozšířená implementace, SSH však označuje především protokol.

Host key a known_hosts

Host key identifikuje server. Klient ukládá přijaté veřejné host keys do known_hosts a při změně varuje, protože změna může být legitimní reinstalace i útok typu man-in-the-middle. Fingerprint prvního klíče je vhodné ověřit jiným důvěryhodným kanálem.

Veřejný a privátní klíč uživatele

Při autentizaci veřejným klíčem server zná autorizovanou veřejnou část a klient prokáže držení privátní části kryptografickým podpisem. Privátní klíč zůstává u uživatele a nemá se kopírovat na spravované servery.

Heslo a více metod

Heslo se ověřuje uvnitř už vytvořeného šifrovaného transportu, takže se neposílá jako otevřený text. Veřejný klíč bývá pro správu praktičtější vůči hádání a automatizaci, ale jen při správné ochraně, rotaci a případné kombinaci s dalším faktorem.

SSH agent

Agent zpřístupňuje načtené identity a provádí podpisové operace bez opakovaného čtení privátního klíče z disku. Agent forwarding se zapíná jen vědomě: kompromitovaný vzdálený host s přístupem k socketu nemusí klíč ukrást, ale může zneužít dostupné podpisové operace.

Forwarding

Lokální forwarding zpřístupní klientovi cíl dosažitelný ze serveru, vzdálený forwarding opačný směr a dynamický forwarding vytvoří SOCKS proxy. Každé přesměrování rozšiřuje síťovou cestu a má být omezené adresou, portem a serverovou politikou.

SSH a TLS

SSH a TLS chrání síťovou komunikaci, ale nejsou zaměnitelné. TLS typicky zabezpečuje aplikační protokoly jako HTTPS a často ověřuje server certifikačním řetězcem; SSH vytváří kanály pro vzdálené služby a běžně pracuje s host keys nebo vlastní SSH certifikační autoritou.

Výhody a omezení

Silný protokol potřebuje stejně pečlivou správu identit a oprávnění

Přínosy

chrání příkazy, výstup i přenášené kanály proti pasivnímu odposlechu a změně po cestě
umožňuje interaktivní i neinteraktivní správu jedním protokolem
autentizaci veřejným klíčem lze bezpečněji automatizovat a omezit pro konkrétní účel
forwarding zpřístupní interní službu bez jejího veřejného vystavení
konfigurace klienta umožňuje pojmenovat host, uživatele, identity i jump hosty

Omezení a časté chyby

slepé přijetí nebo vypnutí kontroly host key ruší důležitou ochranu proti podvrženému serveru
únik nechráněného privátního klíče může otevřít všechny účty, kde je jeho veřejná část autorizovaná
příliš široký forwarding nebo agent forwarding zvětšuje dopad kompromitovaného serveru
přímý root login a sdílené administrační účty zhoršují omezení dopadu i audit
samotná změna výchozího portu neřeší autentizaci, aktualizace ani omezení přístupu

Praktické použití

Vzdálená správa, automatizace a přesně omezené tunely

SSH dává smysl pro diagnostiku serveru, řízený deployment, správu repozitáře nebo krátkodobý přístup k interní službě. Automatizovaný účet má mít samostatnou identitu a jen nezbytná oprávnění; záznam v authorized_keys může navíc omezit příkaz, forwarding, zdrojovou adresu nebo přidělení terminálu.

SSH není náhradou za VPN, správu secrets, auditní systém ani standardní aplikační rozhraní. Pokud mnoho lidí pravidelně provádí ruční produkční změny, je vhodné část práce převést do verzované automatizace a CI/CD. Nouzový přístup přesto zůstává užitečný, pokud je individuální, zaznamenaný a pravidelně revidovaný.

Bezpečnost a provoz

Důvěru v server i uživatele je potřeba umět změnit a odebrat

Klíč není trvalá vstupenka. Bez inventáře autorizací a postupu rotace se po odchodu člověka nebo úniku identity obtížně zjišťuje, kam všude má stále přístup.

privátní klíč nesdílet a chránit jej oprávněními, vhodnou passphrase nebo hardwarovým autentizátorem podle rizika
fingerprint nového či změněného host key ověřit důvěryhodným kanálem, ne pouze smazat varování z known_hosts
preferovanou kombinaci autentizačních metod nastavit podle prostředí a omezit počet účtů s administračními právy
root přístup povolit jen tehdy a takovým způsobem, jaký konkrétní provoz skutečně vyžaduje
po úniku odebrat veřejný klíč nebo certifikační oprávnění ze všech serverů, vydat novou identitu a zkontrolovat logy
pravidelně aktualizovat klienta i server a nepovolovat zastaralé algoritmy jen kvůli nezdokumentovanému starému systému

Časté otázky

SSH klíče, host key a bezpečný přístup

Je SSH jen vzdálený terminál?

Ne. SSH je protokol a sada nástrojů. Interaktivní vzdálený shell je jeden způsob použití vedle spuštění jediného příkazu, přenosu souborů a síťového forwardingu.

Šifruje spojení můj uživatelský veřejný klíč?

Ne přímo. Šifrovaný transport vzniká při výměně klíčů relace. Uživatelský pár klíčů pak slouží k prokázání identity uživatele uvnitř tohoto chráněného spojení.

Co dělat, když SSH hlásí změnu host key?

Nepřepisovat záznam naslepo. Změna může následovat po legitimní reinstalaci, ale také značit podvržený server. Důvod a nový fingerprint nejdřív ověř u správce nebo jiným důvěryhodným kanálem.

Je autentizace klíčem vždy bezpečnější než heslo?

Správně spravovaný klíč bývá pro administraci odolnější vůči hádání hesel a lépe se automatizuje. Bez ochrany privátní části, omezených oprávnění, inventáře a rotace však bezpečný automaticky není.

Co udělat při úniku privátního klíče?

Odeber jeho veřejnou část nebo příslušné certifikační oprávnění ze všech cílových systémů, vytvoř novou identitu a prověř přístupové logy. Passphrase může zneužití zdržet, ale nenahrazuje rotaci.

Jak pracuji se servery

Vzdálený přístup odděluji od oprávnění aplikace i běžného deploymentu.

Při správě aplikací používám individuální přístupy, omezené účty a dohledatelné postupy, aby ruční diagnostika neobcházela provozní pravidla projektu.

Moje technické znalosti Nezávazně probrat projekt

OpenSSH ssh(1) manual