Ve složce projektu stále leží starý administrátorský klíč. Funguje na několika serverech, ale nikdo přesně neví, kdo má jeho kopii. Přechod z hesel na SSH klíče tak změnil přihlašování, aniž vyjasnil odpovědnost.
Použitelná správa SSH spojuje individuální identity, vhodná oprávnění na cílech a spolehlivé odebrání přístupu. Podle prostředí mohou stačit udržované veřejné klíče s řádnou evidencí. Větší nebo často se měnící prostředí mohou využít krátkodobé SSH certifikáty. Obě cesty potřebují zvládnutelný provoz.
Čtyři věci, které se nemají zaměňovat
Soukromý uživatelský klíč umožňuje prokázat vlastní identitu. Uchovává se chráněný a nerozesílá se chatem, e-mailem ani nechráněnou projektovou složkou. Odpovídající veřejný klíč lze uložit na určené cílové systémy a povolit tím přístup. Jeho otisk pomáhá s jednoznačným přiřazením v evidenci.
Hostitelský klíč naopak identifikuje oslovovaný server. Ověření hostitele brání tomu, aby spojení nepozorovaně skončilo u nesprávné protistrany. SSH certifikát doplňuje veřejný klíč o podepsané údaje, například o identitě a platnosti. Certifikáty OpenSSH mají vlastní formát a nejsou běžnými certifikáty TLS/X.509.
Oddělit osobní přihlášení od automatických úloh
Administrativní práce se přiřazuje konkrétním lidem a jejich povoleným úkolům. Společně sdílený dlouhodobý klíč root zbytečně komplikuje odchody, rotaci a dohledatelnost. Lepší základ poskytují individuální přihlášení s vhodně upravenými administrátorskými právy.
Zálohovací nebo nasazovací úloha potřebuje vlastní technickou identitu s doloženou odpovědností. Kde je to možné, omezí se přístup na konkrétní funkci, například vynuceným příkazem a vhodnými pravidly přesměrování. Soukromý klíč zaměstnance se nemá nepozorovaně stát trvalou podmínkou automatické úlohy.
Od evidence klíčů ke krátkodobým certifikátům
U malého počtu systémů může stačit řízená distribuce veřejných klíčů. Evidence zaznamená osobu nebo službu, otisk, cílové systémy, rozsah a plánované datum kontroly či výměny. Rozhodující je spolehlivě udržovat oprávnění na všech dotčených cílech.
Certifikační autorita SSH může místo toho podepisovat veřejné klíče na omezenou dobu a pro určené identity. Servery důvěřují vyhrazené CA a ověřují další pravidla. Soukromý přihlašovací klíč není třeba předávat CA. Klíče CA a pravidla vydávání se chrání zvlášť pečlivě.
Krátká platnost zkracuje dobu použitelnosti vydaného dokladu. Neukončuje však již běžící relaci a nenahrazuje proces odebrání přístupu. Po odchodu osoby je třeba zabránit také vydávání nových certifikátů. Centrální platforma pro správu tajných údajů je jednou z možností provozu; musí skutečně podporovat daný postup SSH.
| Způsob správy | Vhodné použití | Co vyžaduje provoz |
|---|---|---|
| Udržovat veřejné klíče | Přehledný a dobře evidovaný soubor cílů. | Distribuce, odstranění starých oprávnění a zastupitelnost. |
| Vydávat SSH certifikáty | Omezená platnost a určené identity. | Ochrana CA, pravidla vydávání, důvěra serverů a odebrání. |
| Technické identity | Automatizace s jasným úkolem. | Omezená cílová oprávnění, odpovědnost a postup výměny. |
| Agent nebo hardwarový klíč | Vhodné způsoby osobního přihlášení. | Omezení přesměrování, ověření verzí a obnova. |
Agenta a hardwarové klíče používat uvážlivě
SSH agent umožňuje přihlášení pomocí načtených klíčů bez kopírování souboru soukromého klíče na každý cílový server. Přesměrování agenta však vzdálenému systému zpřístupňuje jeho podpisové funkce. OpenSSH výslovně upozorňuje, že útočník s dostatečným přístupem k tomuto systému může načtené identity použít k přihlášení, aniž získá samotné klíče.
Přesměrování agenta se proto povoluje jen pro potřebnou cestu. Podporovaná časová nebo cílová omezení mohou přidat další hranice. Hardwarové bezpečnostní klíče jsou další možností vhodného interaktivního přístupu. Klient, server, typ klíče a požadavek na dotyk nebo PIN musí být kompatibilní; úloha bez obsluhy má jiné potřeby než osobní přihlášení.
Rotace a odvolání musí dosáhnout cíle
Výměna klíče v notebooku neodstraní starý přístup ze serveru. U uložených veřejných klíčů je třeba aktualizovat oprávnění na všech dotčených cílech. Pro certifikáty lze využít také mechanismy jako OpenSSH Key Revocation Lists. Zneplatnění je účinné až tehdy, když je příslušné servery správně uplatňují.
Postup zahrnuje i ztracené zařízení, kompromitovaný klíč a nedostupnou správní službu. Nezávislý nouzový přístup se chrání, dokumentuje a řízeně testuje. Obnova nesmí záviset právě na přístupové cestě, která selhala.
V prostředích Linux a Proxmox postupovat diferencovaně
V různorodých prostředích se zjišťují verze a skutečně podporované funkce OpenSSH. Aktuální příručka nezaručuje stejné možnosti v každé existující instalaci Linuxu. Nová pravidla se zavádějí s určeným testovacím přístupem a ověřenou cestou zpět.
Proxmox VE používá SSH také pro vlastní funkce clusteru, například určité konzolové, migrační a replikační cesty. Tyto technické vztahy důvěry se posuzují odděleně od osobních přístupů administrátorů. Plošné čištění nebo přepisování souborů klíčů může narušit provoz. Změny se proto ověřují podle dokumentace nainstalované verze.
Co obsahuje zvládnutelný začátek
DAXS eviduje stávající SSH přístupy, přiřazuje odpovědnosti a plánuje vhodnou správu. Pilot ověřuje přihlášení, oprávnění, odebrání, protokolování a obnovu. Samotné úspěšné přihlášení nestačí jako přejímací kritérium. Pouhé přihlašovací logy také nejsou automaticky úplným záznamem všech provedených příkazů.
Infrastrukturní služby a článek o Proxmoxu ve firmě zasazují provoz do souvislostí. U sdílených portálů pohled doplňuje článek o trezorech, rolích a odchodech pracovníků . Můžete požádat o inventuru administrátorských přístupů.
Časté dotazy
Mohu předat veřejný klíč?
Veřejná část je určena k vhodné distribuci. Přesto je třeba ověřit přiřazení ke správné osobě a cíli. Soukromá část se chrání a nerozesílá se jako společný přístupový soubor.
Stačí krátkodobý certifikát pro okamžité odebrání přístupu?
Ne. Je třeba společně posoudit vydávání, zbývající platnost, kontrolu odvolání a běžící relace. Krátká platnost tento postup nenahrazuje.
Je centrální certifikační autorita vždy nutná?
Ne. Vhodné řešení určuje rozsah, četnost změn, automatizace a provozní schopnosti. Pečlivě udržovaná správa klíčů může pro přehledný soubor systémů stačit.
Zdroje: OpenSSH: přihlašování a autorizované klíče (externí odkaz) · OpenSSH: certifikáty a seznamy odvolaných klíčů (externí odkaz) · OpenSSH: pravidla důvěry a odvolání na serveru (externí odkaz) · OpenSSH: přesměrování agenta (externí odkaz) · OpenSSH: klíče agenta a omezení (externí odkaz) · Proxmox VE: příručka správce, SSH v clusteru (externí odkaz)
Koncepční přehled; konkrétní funkce závisí na nainstalovaných verzích a plánované správě.
