SSH

SSH, z anglického Secure Shell, je protokol pro zabezpečené přihlášení a vykonávání příkazů na vzdáleném počítači. Chrání komunikaci šifrováním a kontrolou integrity a umožňuje ověřovat server i přihlašovaného uživatele. Používá se například ke správě linuxového serveru bez monitoru. SSH je protokol; OpenSSH je jedna z jeho běžných implementací s klientem ssh a serverovou službou sshd.

Co se ověřuje při připojení

Při spojení jsou důležité dvě různé identity. Klient potřebuje poznat, že se připojil ke správnému serveru. Server naopak potřebuje ověřit uživatele. Klíč serveru, označovaný host key, proto není totéž jako osobní klíč správce používaný k přihlášení.

OpenSSH si známé klíče serverů eviduje například v souboru known_hosts. Při prvním připojení je potřeba otisk porovnat s údajem získaným důvěryhodnou cestou, například z konzole poskytovatele nebo přímo od správce. Slepé potvrzení neznámého klíče ověření správného serveru nenahrazuje.

Upozornění na změněný klíč může znamenat legitimní reinstalaci, ale také připojení k jinému stroji nebo útok. Správný postup je zjistit důvod a ověřit nový otisk. Vypnutí kontroly klíče jen proto, aby hláška zmizela, odstraní důležitou ochranu.

Veřejný a soukromý klíč uživatele

U přihlášení klíčem správce vytvoří dvojici soukromého a veřejného klíče. Veřejnou část umístí na server do povoleného seznamu nebo ji spravuje jiným podporovaným mechanismem. Klient při přihlášení prokazuje držení soukromé části podpisem; soukromý klíč se na server neposílá.

V běžné konfiguraci OpenSSH obsahuje ~/.ssh/authorized_keys veřejné klíče povolené pro daný účet. Nejde o seznam serverů a nesmí se do něj kopírovat soukromý klíč. Skutečnou cestu i pravidla určuje konfigurace služby. Správně vypadající soubor nepomůže, pokud se správce přihlašuje pod jiným účtem.

Soukromý klíč je možné chránit přístupovou frází. Její smysl se liší od hesla serverového účtu: chrání uložený klíč při jeho odcizení. Ztracený nebo kompromitovaný klíč je potřeba odstranit z povolených přístupů. Jeden klíč s širokými právy na mnoho strojů zároveň zvětšuje dopad jeho úniku.

Příklad připojení a diagnostiky

Modelový příkaz níže se připojí jako účet spravce na dokumentační adresu. Adresa 192.0.2.10 patří do rozsahu určeného pro příklady; nenahrazuje adresu skutečného serveru:

ssh -i ~/.ssh/id_ed25519 spravce@192.0.2.10
ssh -v -i ~/.ssh/id_ed25519 spravce@192.0.2.10

Volba -i vybírá soubor identity a -v přidá diagnostický výpis. Ten pomůže odlišit, jestli se nedaří navázat síťové spojení, ověřit server nebo přihlásit uživatele. Výpis může obsahovat názvy strojů, účtů a cest, proto je před veřejným sdílením vhodné zkontrolovat jeho obsah.

SSH běžně používá TCP port 22, server ale může poslouchat jinde. V takovém případě klient používá například volbu -p. Úspěšný ping nepotvrzuje otevřený port a otevřený port nepotvrzuje platné přihlášení. „Connection refused“, časový limit spojení a „Permission denied“ popisují různé situace.

Když správný klíč nefunguje

Mezi příčiny patří jiný účet, prázdný nebo poškozený seznam povolených klíčů, výběr jiné identity v klientovi nebo omezení v konfiguraci serveru. OpenSSH může odmítnout soubory také kvůli nevhodnému vlastníkovi a oprávněním. V unixovém prostředí se běžně používají práva 700 pro adresář .ssh a 600 pro authorized_keys; rozhodující je ovšem celá konfigurace a vlastnictví.

Vypínat kontrolu práv nebo povolovat přihlášení privilegovaného účtu není vhodná univerzální oprava. Nejprve je lepší porovnat veřejný klíč, cílový účet, cestu a autentizační záznamy. Pokud přístup vůbec nefunguje, může být potřebná konzole nebo přístup k úložišti mimo SSH.

SSH není správce běžících úloh

Protokol umí více než interaktivní terminál: také vzdálené příkazy a podle nastavení přenos souborů přes SFTP nebo tunelování spojení. Tunel ale sám nezabezpečí špatně nastavenou aplikaci a automatizace by měla dostat pouze potřebná oprávnění. Přihlášení jako správce celého systému není podmínkou každé diagnostiky.

Životnost programu spuštěného z terminálu závisí na způsobu spuštění a prostředí. SSH samo nezajistí automatický start po restartu ani obnovu po pádu. V článku o Raspberry Pi proto SSH slouží ke správě, zatímco samostatný worker běží jako služba systemd. Zavření dashboardu nebo správcovského spojení jeho běh neřídí.