known_hosts soubor umožňuje klientovi ověřit server, aby zkontroloval, že se nepřipojuje k napodobiteli. authorized_keys soubor umožňuje serveru ověřit uživatele.
Ověření serveru
Jedna z prvních věcí, která se stane při navazování SSH spojení, je, že server odešle svůj veřejný klíč klientovi a prokáže (díky kryptografii veřejného klíče) klientovi, že zná přidružený soukromý klíč. Tím se ověří server:pokud je tato část protokolu úspěšná, klient ví, že server je tím, za koho se vydává.
Klient může zkontrolovat, že server je známý, a ne nějaký nepoctivý server, který se snaží vydávat za správný. SSH poskytuje pouze jednoduchý mechanismus pro ověření legitimity serveru:pamatuje si servery, ke kterým jste se již připojili, v ~/.ssh/known_hosts soubor na klientském počítači (existuje také celosystémový soubor /etc/ssh/known_hosts ). Když se poprvé připojujete k serveru, musíte nějakým jiným způsobem zkontrolovat, že veřejný klíč prezentovaný serverem je skutečně veřejný klíč serveru, ke kterému se chcete připojit. Pokud máte veřejný klíč serveru, ke kterému se chystáte připojit, můžete jej přidat do ~/.ssh/known_hosts na klientovi ručně.
Mimochodem, known_hosts může obsahovat jakýkoli typ veřejného klíče podporovaného implementací SSH, nejen DSA (také RSA a ECDSA).
Před odesláním jakýchkoli důvěrných dat na server je nutné provést ověření. Zejména pokud autentizace uživatele zahrnuje heslo, nesmí být heslo odesláno na neověřený server.
Ověření uživatele
Server umožňuje přihlášení vzdáleného uživatele pouze v případě, že tento uživatel může prokázat, že má právo přístupu k tomuto účtu. V závislosti na konfiguraci serveru a volbě uživatele může uživatel předložit jednu z několika forem pověření (níže uvedený seznam není vyčerpávající).
- Uživatel může předložit heslo k účtu, ke kterému se pokouší přihlásit; server poté ověří, zda je heslo správné.
- Uživatel může předložit veřejný klíč a prokázat, že vlastní soukromý klíč spojený s tímto veřejným klíčem. Toto je přesně stejná metoda, která se používá k ověření serveru, ale nyní se uživatel snaží prokázat svou identitu a server ji ověřuje. Pokus o přihlášení je přijat, pokud uživatel prokáže, že zná soukromý klíč a veřejný klíč je v seznamu oprávnění účtu (
~/.ssh/authorized_keysna serveru). - Další typ metody zahrnuje delegování části práce ověřování uživatele na klientský počítač. K tomu dochází v kontrolovaných prostředích, jako jsou podniky, kdy mnoho strojů sdílí stejné účty. Server ověřuje klientský počítač stejným mechanismem, který se používá opačně, a pak se spoléhá na klienta, že ověří uživatele.
Tyto dva soubory používá SSH, ale pro zcela odlišné účely, což by mohlo snadno vysvětlit váš zmatek.
Autorizované klíče
Ve výchozím nastavení SSH používá uživatelské účty a hesla spravovaná hostitelským OS. (No, ve skutečnosti to spravuje PAM, ale tento rozdíl zde pravděpodobně není příliš užitečný.) To znamená, že když se pokusíte připojit k SSH s uživatelským jménem 'bob' a nějakým heslem, program serveru SSH se zeptá OS "I mám toho chlapa jménem 'bob', který mi říká, že jeho heslo je 'wonka'. Mohu ho pustit dovnitř?" Pokud je odpověď ano, pak vám SSH umožní autentizaci a můžete pokračovat svou veselou cestou.
Kromě hesel vám SSH také umožní používat k vaší identifikaci to, čemu se říká kryptografie s veřejným klíčem. Specifický šifrovací algoritmus se může lišit, ale obvykle je to RSA nebo DSA, nebo nověji ECDSA. V každém případě při nastavování klíčů pomocí ssh-keygen vytvoříte dva soubory. Jeden, který je vaším soukromým klíčem a jeden, který je vaším veřejným klíčem. Názvy jsou poměrně samozřejmé. Podle návrhu může být veřejný klíč rozházen jako semena pampelišky ve větru, aniž by vás to ohrozilo. Soukromý klíč by měl být vždy uchováván v nejpřísnější tajnosti.
Takže co uděláte, je umístit váš veřejný klíč do authorized_keys soubor. Když se pak pokusíte připojit k SSH s uživatelským jménem 'bob' a vaším soukromým klíčem, zeptá se OS "Mám toho chlapa se jménem 'bob', může tu být?" Pokud je odpověď ano, SSH zkontroluje váš soukromý klíč a ověří, zda je veřejný klíč v authorized_keys soubor je jeho pár. Pokud jsou obě odpovědi ano, pak jste povoleni.
Známí hostitelé
Podobně jako authorized_keys soubor se používá k ověření uživatelů known_hosts soubor se používá k ověřování serverů. Kdykoli je SSH nakonfigurováno na novém serveru, vždy vygeneruje veřejný a soukromý klíč pro server, stejně jako jste to udělali pro svého uživatele. Pokaždé, když se připojíte k serveru SSH, zobrazí vám svůj veřejný klíč spolu s důkazem, že vlastní odpovídající soukromý klíč. Pokud nemáte jeho veřejný klíč, váš počítač si jej vyžádá a přidá ho do known_hosts soubor. Pokud máte klíč a shoduje se, pak se rovnou připojíte. Pokud se klíče neshodují, dostanete velké ošklivé varování. Tady jsou věci zajímavé. Ke 3 situacím, ke kterým obvykle dochází k nesouladu klíčů, patří:
- Klíč se na serveru změnil. Může to být způsobeno přeinstalací operačního systému nebo v některých operačních systémech se klíč znovu vytvoří při aktualizaci SSH.
- Název hostitele nebo adresa IP, ke které se připojujete, patřily k jinému serveru. Může to být změna přiřazení adresy, DHCP nebo něco podobného.
- Dochází ke škodlivému útoku typu man-in-the-middle. To je největší věc, před kterou se vás kontrola klíčů snaží chránit.
V obou případech known_hosts a authorized_keys , program SSH používá k identifikaci klienta nebo serveru kryptografii veřejného klíče.
O zabezpečených souborech obsahujících veřejné klíče
Abychom vám pomohli pochopit, jak se liší „known_hosts“ a „authorized_keys“, zde je kontext vysvětlující, jak tyto soubory zapadají do „ssh“. Toto je přílišné zjednodušení; "ssh" má mnohem více možností a komplikací, než je zde zmíněno.
Asociace jsou v důvěryhodných zdrojích
I když bylo řečeno, že hodnoty veřejného klíče „mohou být bezpečně obsypány jako semena ve větru“, mějte na paměti, že o tom, která semena se v zahradě usadí, rozhoduje zahradník, nikoli semeno. Přestože veřejný klíč není tajný, je vyžadována přísná ochrana, aby se zachovalo důvěryhodné spojení klíče s věcí, kterou klíč ověřuje. Mezi místa pověřená vytvořením tohoto spojení patří výpisy „známí_hostitelé“, „autorizované_klíče“ a „Certifikační autorita“.
Důvěryhodné zdroje používané "ssh"
Aby byl veřejný klíč relevantní pro „ssh“, musí být klíč zaregistrován předem a uložen v příslušném zabezpečeném souboru. (Tato obecná pravda má jednu důležitou výjimku, o které bude řeč později.) Server i klient mají svůj vlastní, bezpečně uložený seznam veřejných klíčů; přihlášení bude úspěšné, pouze pokud je každá strana registrována u druhé.
- „known_hosts“ se nachází na klientovi
- „authorized_keys“ se nachází na serveru
Zabezpečený soubor klienta se nazývá „known_hosts“ a zabezpečený soubor serveru se nazývá „authorized_keys“. Tyto soubory jsou podobné v tom, že každý má text s jedním veřejným klíčem na řádek, ale mají jemné rozdíly ve formátu a použití.
Páry klíčů se používají k ověření
K provádění "asymetrické kryptografie" se používá pár veřejného a soukromého klíče. Program "ssh" může pro autentizaci používat asymetrickou kryptografii, kdy entita musí odpovědět na výzvu, aby prokázala svou identitu. Výzva je vytvořena kódováním jedním klíčem a zodpovězena dekódováním druhým klíčem. (Upozorňujeme, že asymetrická kryptografie se používá pouze během fáze přihlášení; poté se „ssh“ (TSL/SSL) přepne na jinou formu šifrování, aby zpracoval datový tok.)
Jeden pár klíčů pro server, druhý pro klienta
V "ssh" jsou obě strany (klient i server) vůči té druhé podezřívavé; toto je vylepšení oproti předchůdci "ssh", což bylo "telnet". U „telnetu“ byl klient požádán o zadání hesla, ale server nebyl prověřen. Nedostatek prověřování umožnil výskyt útoků typu „man-in-the-middle“, což mělo katastrofální důsledky pro bezpečnost. Naproti tomu v procesu "ssh" se klient nevzdává žádné informace, dokud server nejprve neodpoví na výzvu.
Postup při ověřování "ssh"
Před sdílením jakýchkoliv přihlašovacích údajů klient "ssh" nejprve eliminuje příležitost k útoku typu man-in-the-middle tím, že vyzve server, aby prokázal:"Jsi opravdu ten, kdo si myslím, že jsi?" K provedení této výzvy musí klient znát veřejný klíč, který je přidružen k cílovému serveru. Klient musí najít název serveru v souboru "known_hosts"; přidružený veřejný klíč je na stejném řádku za názvem serveru. Asociace mezi názvem serveru a veřejným klíčem musí zůstat neporušená; proto oprávnění k souboru "known_hosts" musí být 600 -- nikdo jiný nemůže zapisovat (ani číst).
Jakmile se server ověří, dostane příležitost vyzvat klienta. Autentizace bude zahrnovat jeden z veřejných klíčů nalezených v "authorized_keys". (Pokud žádný z těchto klíčů nefunguje, proces "sshd" se vrátí zpět na ověřování stylem hesla.)
Formáty souborů
Takže pro "ssh", stejně jako pro jakýkoli proces přihlášení, existují seznamy "přátel" a pouze ti na seznamu se mohou pokusit projít výzvou. Pro klienta je soubor "known_hosts" seznam přátel, kteří mohou fungovat jako servery (hostitelé); tyto jsou uvedeny podle názvu. Pro server je ekvivalentním seznamem přátel soubor "authorized_keys"; ale v tomto souboru nejsou žádná jména, protože samotné veřejné klíče fungují jako identifikátory. (Server se nestará o to, odkud přihlášení pochází, ale pouze kam. Klient se pokouší o přístup ke konkrétnímu účtu, název účtu byl zadán jako parametr při vyvolání "ssh". Pamatujte, že "authorized_keys" " je specifický pro tento účet, protože soubor je v domovském adresáři tohoto účtu.)
Ačkoli existuje mnoho schopností, které lze vyjádřit v konfiguračním záznamu, základní a nejběžnější použití má následující parametry. Pamatujte, že parametry jsou odděleny mezerami.
Pro "known_hosts":
{server-id} ssh-rsa {public-key-string} {comment}
Pro "authorized_keys":
ssh-rsa {public-key-string} {comment}
Všimněte si, že token ssh-rsa označuje, že algoritmus použitý pro kódování je "rsa". Mezi další platné algoritmy patří „dsa“ a „ecdsa“. Proto může místo ssh-rsa nahradit jiný token zobrazeno zde.
Nechte "ssh" automaticky konfigurovat položku "known_hosts"
V obou případech, pokud není veřejný klíč nalezen v zabezpečeném souboru, pak k asymetrickému šifrování nedojde. Jak již bylo zmíněno, existuje jedna výjimka z tohoto pravidla. Uživatel se může vědomě rozhodnout riskovat možnost útoku typu man-in-the-middle přihlášením na server, který není uveden v souboru „known_hosts“ uživatele. Program "ssh" varuje uživatele, ale pokud se uživatel rozhodne jít vpřed, klient "ssh" to umožní "jen jednou." Aby se zajistilo, že se to stane pouze jednou, proces "ssh" automaticky nakonfiguruje soubor "known_hosts" s požadovanými informacemi tak, že požádá server o veřejný klíč a poté jej zapíše do souboru "known_hosts". Tato výjimka zcela podvrací zabezpečení tím, že umožňuje protivníkovi poskytnout spojení názvu serveru s veřejným klíčem. Toto bezpečnostní riziko je povoleno, protože tolik lidem usnadňuje věci. Samozřejmě správnou a bezpečnou metodou by bylo, kdyby uživatel ručně vložil řádek s názvem serveru a veřejným klíčem do souboru "known_hosts" dříve, než se vůbec pokusí přihlásit k serveru. (Ale v situacích s nízkým rizikem může být práce navíc zbytečná.)
Vztahy jeden k mnoha
Záznam v klientově souboru "known_hosts" má název serveru a veřejný klíč, který je použitelný pro serverový stroj. Server má jeden soukromý klíč, který se používá k zodpovězení všech výzev, a položka „known_hosts“ klienta musí mít odpovídající veřejný klíč. Všichni klienti, kteří kdy přistupují k určitému serveru, tedy budou mít ve svém souboru "known_hosts" stejný záznam veřejného klíče. Vztah 1:N spočívá v tom, že veřejný klíč serveru se může objevit v mnoha klientových souborech "known_hosts".
Záznam v souboru "authorized_keys" označuje, že přátelský klient má povolen přístup k účtu. Přítel může použít stejný pár veřejného a soukromého klíče pro přístup k více různým serverům. To umožňuje autentizaci jediného páru klíčů na všech serverech, které byly kdy kontaktovány. Každý z cílových účtů serveru by měl ve svých souborech "authorized_keys" stejný záznam veřejného klíče. Vztah 1:N spočívá v tom, že veřejný klíč jednoho klienta se může objevit v souborech „authorized_keys“ pro více účtů na více serverech.
Někdy uživatelé, kteří pracují z více klientských počítačů, replikují stejný pár klíčů; obvykle se to provádí, když uživatel pracuje na stolním počítači a přenosném počítači. Protože se klientské počítače ověřují identickými klíči, budou odpovídat stejné položce v "authorized_keys" serveru.
Umístění soukromých klíčů
Na straně serveru zpracovává všechny příchozí požadavky na přihlášení „ssh“ systémový proces neboli démon. Démon se jmenuje "sshd". Umístění soukromého klíče závisí na instalaci SSL, například Apple jej uvádí na /System/Library/OpenSSL , ale po instalaci vlastní verze OpenSSL bude umístění /opt/local/etc/openssl .
Na straně klienta vyvoláte "ssh" (nebo "scp"), když to potřebujete. Váš příkazový řádek bude obsahovat různé parametry, z nichž jeden může volitelně určovat, který soukromý klíč se má použít. Ve výchozím nastavení se pár klíčů na straně klienta často nazývá $HOME/.ssh/id_rsa a $HOME/.ssh/id_rsa.pub .
Shrnutí
Sečteno a podtrženo, „známí_hostitelé“ i „autorizované_klíče“ obsahují veřejné klíče, ale ...
- známí_hostitelé – klient zkontroluje, zda je hostitel pravý
- authorized_keys – hostitel zkontroluje, zda je povoleno přihlášení klienta