Soubor known_hosts umožňuje klientovi ověřit server a zkontrolovat, zda se nepřipojuje k imitátorovi. Soubor authorized_keys umožňuje server ověřuje uživatele.

Ověřování serveru

Jednou z prvních věcí, které se stanou při navazování připojení SSH, je to, že server odešle 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: je-li tato část protokolu úspěšná, klient ví, že server je tím, kým tvrdí, že je.

Klient může zkontrolovat, zda je server známý, a ne nějaký nepoctivý server se snaží vydávat za správné. SSH poskytuje pouze jednoduchý mechanismus k ověření legitimity serveru: pamatuje si servery, ke kterým jste již připojeni, v souboru ~/.ssh/known_hosts na klientském počítači (existuje také systém -wide file /etc/ssh/known_hosts). Při prvním připojení k serveru musíte nějakým jiným způsobem zkontrolovat, že veřejný klíč předložený serverem je skutečně veřejným klíčem serveru ke kterému jste se chtěli 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).

Ověření před odesláním jakýchkoli důvěrných dat. Zejména pokud ověřování uživatele zahrnuje heslo, heslo se nesmí zasílat 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 mohou prokázat, že mají právo na přístup 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 pro účet, 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. Jedná se o přesně stejnou metodu, která se používá k ověření serveru, ale nyní se uživatel pokouší 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_keys na serveru).
• Další typ metody zahrnuje delegování části práce s ověřováním uživatele na klientský počítač. K tomu dochází v kontrolovaných prostředích, jako jsou podniky, když mnoho počítačů sdílí stejné účty. Server ověřuje klientský počítač stejným mechanismem, který je použil naopak, pak se při ověřování uživatele spoléhá na klienta.

Komentáře

• díky, to je velmi užitečné. By je správné říci, že soubor known_hosts je udržován na klientovi, zatímco soubor authorized_key je udržován na serveru
• @Ankit Ano, to je ten případ.
• Mám oba soubory na serveru a ssh to vyzkoušet. Ale tyto 2 soubory mají odlišný obsah. Takže klíče se v těchto souborech liší?
• @Timo Klíče jsou úplně unr nadšený. Jeden je klíč stroje, druhý je klíč uživatele.
• @Gilles Takže jakmile je přidán záznam pro veřejný klíč serveru ‚ do souboru known_hosts na klientském počítači ‚ s, jakákoli následná relace ssh mezi těmito dvěma ‚ t požadovat, aby server prokázal, že má správný soukromý klíč?

Oba tyto soubory používá SSH , ale pro úplně jiné účely, které by mohly snadno vysvětlit vaši nejasnost.

Autorizované klíče

Ve výchozím nastavení SSH používá uživatelské účty a hesla, která jsou spravována hostitelským operačním systémem. (No, ve skutečnosti spravováno 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 pomocí uživatelského jména „bob“ a nějaké heslo, které program serveru SSH požádá OS “ Dostal jsem toho chlápka 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 budete pokračovat veselou cestou.

Kromě hesel SSH vám také umožní identifikovat vás pomocí tzv. kryptografie veřejného klíče . Specifický šifrovací algoritmus se může lišit, ale obvykle se jedná o RSA nebo DSA nebo nověji ECDSA . V každém případě, když nastavujete klíče, použijte ssh-keygen vytvoříte dva soubory. Jeden je váš soukromý klíč a druhý váš veřejný klíč. Názvy jsou docela vlastní – vysvětlující. Podle návrhu může být veřejný klíč rozptýlen jako semena pampelišky ve větru, aniž by vás kompromitoval. Soukromý klíč by měl být vždy uchováván v nejpřísnější důvěře.

Takže to, co děláte, je umístění vašeho veřejného zadejte soubor authorized_keys. Poté, když se pokusíte připojit k SSH pomocí uživatelského jména „bob“ a váš soukromý klíč se zeptá OS “ Mám jméno toho chlápka „bob“, můžu být tady? “ Pokud je odpověď ano, pak SSH zkontroluje váš soukromý klíč a ověří, zda je veřejný klíč v souboru authorized_keys jeho pár. Pokud jsou obě odpovědi ano, pak jste povoleni.

Známí hostitelé

Podobně jako se používá soubor authorized_keys k ověřování uživatelů soubor known_hosts se používá k ověření serverů. Kdykoli je SSH nakonfigurován na novém serveru, vždy vygeneruje veřejný a soukromý klíč pro server, stejně jako pro vašeho uživatele. Pokaždé, když se připojíte k serveru SSH, zobrazí vám jeho veřejný klíč spolu s důkazem, že vlastní odpovídající soukromý klíč. Pokud nemáte jeho veřejný klíč, počítač ho o to požádá a přidá jej do souboru known_hosts. Pokud máte klíč a ten se shoduje, ihned se připojíte. Pokud se klíče neshodují, dostanete velké ošklivé varování. To je místo, kde se věci stávají zajímavými. K třem situacím, které se obvykle neshodují, patří:

1. Klíč se změnil na serveru. Může to být z přeinstalování OS nebo v některých OS se klíč znovu vytvoří při aktualizaci SSH.
2. Název hostitele nebo adresa IP, kterou se připojujete dříve patřil jinému serveru. Může to být změna adresy, DHCP nebo něco podobného.
3. Škodlivý muž- dochází k střednímu útoku . Toto 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á kryptografii veřejného klíče k identifikaci klienta nebo serveru.

Komentáře

• “ Pokaždé, když se připojíte k serveru SSH, předloží svůj soukromý klíč, aby prokázal svou totožnost. “ Určitě doufám, že ne! Předpokládám, že jste mysleli jeho veřejný klíč . Pokud by mě server představil, klient by se svým soukromým klíčem – (A) nepracoval ‚ pro jeho ověření a (B) je známkou toho, že server je tak špatně nakonfigurován, že bych s tím měl okamžitě přestat obchodovat. Soukromé klíče by měly být na původním počítači přístupné pouze určeným uživatelům. To ‚ to má smysl. 😉
• Tato odpověď mi pomohla víc než ta přijatá (:
• Pokud ssh na místní server (místní IP), a později ze stejného počítače, ale nyní vzdáleně připojíte se ke stejnému serveru (veřejná IP), způsobí to nesoulad klíčů? Jak to můžete zmírnit?

O zabezpečených souborech obsahujících veřejné klíče

Abychom vám pomohli pochopit, v čem se liší „known_hosts“ a „authorized_keys“, je zde vysvětlen kontext, jak tyto soubory zapadají do „ssh“. ; „ssh“ má mnohem více schopností a komplikací, než je zde uvedeno.

Sdružení jsou v důvěryhodných zdrojích

I když již bylo řečeno, že hodnoty veřejného klíče „mohou být bezpečně rozptýleny jako semena ve větru“, mějte na paměti, že je to zahradník, nikoli osivo, které rozhoduje o tom, která semena se v zahradě usadí. Ačkoli veřejný klíč není tajný, je nutná tvrdá ochrana, aby se zachovala důvěryhodná asociace klíče s věcí, kterou klíč ověřuje. Místa pověřen vytvořením tohoto přidružení zahrnují seznamy „known_hosts“, „authorized_keys“ a „Certificate Authority“.

Důvěryhodné zdroje používané „ssh“

Aby byl veřejný klíč relevantní pro „ssh“, klíč musí být zaregistrován předem a uložen do příslušného zabezpečeného souboru. (Tato obecná pravda má jednu důležitou výjimku, o které bude pojednáno později.) Server i klient mají každý svůj vlastní, bezpečně uložený seznam veřejných klíčů; přihlášení bude úspěšné, pouze pokud bude každá strana zaregistrována u druhé.

• „known_hosts“ je umístěn na clie nt
• „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í.

K ověření se používají páry klíčů

Veřejný – soukromý pár klíčů se používá k provádění „asymetrické kryptografie“. Program „ssh“ může pro ověřování používat asymetrickou kryptografii, kde musí účetní jednotka prokázat svou totožnost výzvou. Výzva je vytvořena kódováním pomocí jednoho klíče a odpovídá dekódováním pomocí druhého klíče. (Všimněte si, že asymetrická kryptogrofie se používá pouze během fáze přihlášení; poté se „ssh“ (TSL / SSL) přepne na jinou formu šifrování za účelem zpracování datového proudu.)

Jeden pár klíčů pro server, jiný pro klienta

V „ssh“ jsou obě strany (klient i server) vůči druhé podezřelé; jde o vylepšení oproti předchůdci „ssh“, kterým byl „telnet“. U služby „telnet“ byl klient povinen poskytnout heslo, ale server nebyl prověřen. Nedostatek prověřování umožňoval útoky typu „člověk ve středu“, což mělo katastrofické důsledky pro bezpečnost. Naproti tomu v procesu „ssh“ se klient vzdá žádné informace, dokud server nejprve neodpoví na výzvu.

Kroky v ověřování „ssh“

Před sdílením jakýchkoli přihlašovacích údajů klient „ssh“ nejprve eliminuje možnost útoku typu „man-in-the-middle“ tím, že vyzve server, aby prokázal „Jste opravdu tím, kým si myslím?“ 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. Přidružení mezi názvem serveru a veřejným klíčem musí být zachováno nedotčené; proto oprávnění na soubor „known_hosts“ musí být 600 – nikdo jiný nemůže psát (ani číst).

Jakmile se server autentizuje, dostane šanci vyzvat klienta. Ověření bude zahrnovat jednu z veřejných klíče nalezené v „authorized_keys“. (Pokud žádný z těchto klíčů nefunguje, proces „sshd“ se opírá o autentizaci pomocí stylu hesla.)

Formáty souborů

Takže pro „ ssh „, stejně jako u každého procesu přihlášení, existují seznamy“ přátel „a pouze ti v seznamu se mohou pokusit předat výzvu. Pro klienta je soubor“ known_hosts „seznam přátel, kteří mohou fungovat jako servery (hostitelé); jsou uvedeny podle jména. Pro server je ekvivalentním seznamem přátel soubor „authorized_keys“; v tomto souboru však nejsou žádná jména, protože publi Samotné klíče c fungují jako identifikátory. (Server se nestará o to, odkud pochází přihlášení, ale pouze o to, kde jde. Klient se pokouší získat přístup k určitému účtu, název účtu byl zadán jako parametr při vyvolání „ssh“. Pamatujte, že Soubor „authorized_keys“ je specifický pro tento účet, protože soubor je v domovském adresáři daného účtu.)

Ačkoli v konfigurační položce lze vyjádřit mnoho funkcí, základní a nejběžnější použití má následující parametry. Upozorňujeme, ž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} 

Upozorňujeme, že token ssh-rsa naznačuje, že algoritmus použitý pro kódování je „rsa“. Jiné platné algoritmy zahrnout „dsa“ a „ecdsa“. Proto zde uvedený ssh-rsa může nahradit jiný token.

Nechte „ssh“ automaticky konfigurovat „known_hosts“ Entry

V obou případech, pokud th Veřejný klíč se nenachází v zabezpečeném souboru, asymetrické šifrování se tedy nestane. Jak již bylo zmíněno dříve, z tohoto pravidla existuje jedna výjimka.Uživatel se může vědomě rozhodnout, že bude 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“ uživatele varuje, ale pokud se uživatel rozhodne přejít vpřed, klient „ssh“ to povolí „pouze jednou.“ Aby bylo zajištěno, že k tomu dojde jen jednou, proces „ssh“ automaticky nakonfiguruje soubor „known_hosts“ s požadovanými informacemi tím, že požádá server o veřejný klíč a poté jej zapsat do souboru „known_hosts“. Tato výjimka zcela narušuje zabezpečení tím, že umožňuje protivníkovi poskytnout přidružení názvu serveru k veřejnému klíči. Toto bezpečnostní riziko je povoleno, protože to vše dělá tolik jednodušší pro tolik lidí. Správnou a bezpečnou metodou by samozřejmě bylo, kdyby uživatel ručně vložil řádek se jménem serveru a veřejným klíčem do souboru „known_hosts“, než se kdykoli pokusí přihlásit na server. (Ale pro situace s nízkým rizikem může být práce navíc zbytečná.)

Vztahy mezi dvěma osobami

Položka v klientském souboru „known_hosts“ má název serveru a veřejný klíč, který je použitelný pro serverový počítač. 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íč. Proto budou mít všichni klienti, kteří někdy přistupují na konkrétní server, stejný veřejný klíč položka v jejich souboru „known_hosts“. Relace 1: N spočívá v tom, že veřejný klíč serveru se může objevit v mnoha souborech „known_hosts“ klienta.

Položka v souboru „authorized_keys“ identifikuje že přátelskému klientovi je 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 jednomu páru klíčů ověřit se na všech serverech, které byly kdy kontaktovány. Každý z cílených serverových účtů by měli ve svých souborech „authorized_keys“ stejnou položku veřejného klíče. Relace 1: N je, ž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 děje, když uživatel pracuje na stolním a přenosném počítači. Protože se klientské počítače autentizují pomocí identických klíčů, budou se shodovat se stejnou položkou na serveru „s“ authorized_keys “.

Umístění soukromých klíčů

Na straně serveru je to systémový proces „Démon“ zpracovává všechny příchozí požadavky na přihlášení „ssh“. Démon má název „sshd“. Umístění soukromého klíče závisí na instalaci SSL, například Apple jej umístí 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ě specifikovat, který soukromý klíč 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í

Závěrem je, že jak „known_hosts“, tak „authorized_keys“ obsahují veřejné klíče, ale …

• known_hosts – klient zkontroluje, zda je hostitel skutečný
• authorized_keys – hostitel kontroluje, zda je povoleno přihlášení klienta

Komentáře

• Klienti SSH obvykle don ‚ nemá klíče. Veřejné klíče uvedené v authorized_keys identifikují uživatele, nikoli stroje.
• Děkujeme. Toto je velmi jasné a snadno srozumitelné vysvětlení vztahů mezi soubory a klíči.

Není to vůbec pravda.

Soubor known_hosts obsahuje otisk prstu hostitele. Nejedná se o veřejný ani soukromý klíč vzdáleného hostitele.

Je generován z jejich klíče – ale důrazně to NENÍ samotný klíč.

Pokud používáte SFTP na adresu, která může vyřešit několik (různých) hostitelů (vyvážené zatížení atd.), musíte přidat otisky prstů ze všech možných koncových bodů, nebo to bude fungovat zpočátku a poté selže, když bude směrováno na druhého (nebo následujícího) hostitele.

Komentáře

• podívejte se na svůj soubor known_hosts a porovnejte jej s otiskem hostitele, když se připojíte …. To by to mělo trochu vyčistit. Váš příklad by byl navíc úplně stejný, bez ohledu na to, zda se jedná o otisky prstů nebo veřejné klíče v souboru known_hosts.