it-swarm-eu.dev

Je použití veřejného klíče pro přihlášení k SSH lepší než uložení hesla?

Použití veřejného/soukromého páru klíčů je docela vhodné pro přihlášení k častým hostitelům, ale pokud používám pár klíčů bez hesla, je to bezpečnější (nebo méně bezpečné) než heslo? Zabezpečení kolem mého souboru soukromého klíče je prvořadé, ale říkají, že můj magický soubor soukromého klíče byl jen seznam hesel pro různé hostitele, je tu nějaký rozdíl?

69
Nick T

Moje odpověď je, že použití párů veřejných klíčů je mnohem moudřejší věc než použití hesel nebo seznamů hesel. Zaměřím se na věci, které nejsou obecně známé o různých formách autentizace SSH, a nevidím žádné další odpovědi, které by je zmiňovaly.

Nejprve musíte pochopit, že ověřování uživatelů je jiný a samostatný proces než vytvoření zabezpečeného kanálu . To laicky znamená, že nejprve se použije veřejný klíč serveru (pokud je akceptován!) K vytvoření zabezpečeného kanálu SSH, umožněním vyjednávání symetrického klíče, který bude použit k ochraně zbývající relace, povolení kanálu důvěrnost, ochrana integrity a autentizace serveru.

Po je kanál funkční a bezpečný, probíhá autentizace uživatele. Dva obvyklé způsoby, jak toho dosáhnout, je pomocí hesla nebo páru veřejných klíčů. Ověřování na základě hesla funguje tak, jak si dokážete představit: Klient odešle své heslo přes zabezpečený kanál, server ověří, že se jedná o heslo konkrétního uživatele a umožňuje přístup. V případě veřejného klíče máme velmi odlišnou situaci. V tomto případě má server veřejný klíč uživatele uložen. Dále se stane, že server vytvoří náhodnou hodnotu (nonce), zašifruje ji veřejným klíčem a odešle ji uživateli. Je-li uživatel, kdo má být, může výzvu dešifrovat a odeslat ji zpět na server, který poté potvrdí totožnost uživatele. Je to klasický model výzva-odpověď. (Ve SSHv2 se skutečně používá něco trochu jiného, ​​ale koncepčně blízkého)

Jak si dokážete představit, v prvním případě je heslo skutečně odesláno na server (pokud SSH nepoužije odpověď na výzvu k zadání hesla), ve druhém soukromý klíč nikdy neopustí klienta. V imaginárním scénáři, že někdo zachytí přenos SSL a je schopen jej dešifrovat (pomocí kompromitovaného soukromého klíče serveru nebo pokud přijmete nesprávný veřejný klíč při připojení k serveru) nebo má přístup k serveru nebo klientovi, vaše heslo bude známo - při autentizaci pomocí veřejného a soukromého klíče a modelu reakce na výzvu vaše soukromé údaje nikdy nespadnou do rukou útočníka. Takže i když je jeden server, ke kterému se připojujete, ohrožen, jiné servery, pro které používáte stejný klíč, by nebyly!

Použití páru veřejných klíčů má i další výhody: Soukromý klíč by neměl být uložen v čistém textu v klientském počítači, jak navrhujete. To samozřejmě ponechá soubor soukromého klíče otevřený kompromisu, jak by to udělal nešifrovaný soubor hesla, ale je jednodušší dešifrovat (při přihlášení) a použít soukromý klíč. Mělo by být uloženo šifrováno, a je třeba, abyste poskytli obvykle dlouhé přístupové heslo pro jeho dešifrování při každém použití.

To samozřejmě znamená, že budete muset poskytnout dlouhou přístupovou frázi pokaždé, když se připojíte k serveru, abyste odemkli svůj soukromý klíč - existují způsoby, jak to vyřešit. Použitelnost systému můžete zvýšit pomocí autentizačního agenta: Jedná se o kus softwaru, který odemkne vaše klíče pro aktuální relaci, když se například přihlásíte do gnome nebo když poprvé ssh do svého klienta, takže stačí napište 'ssh remote-system-ip' a přihlaste se, aniž byste zadali přístupové heslo, a to několikrát, dokud se neodhlásíte ze své relace.

Abych to shrnul, použití párů veřejných klíčů nabízí mnohem větší ochran než použití hesel nebo seznamů hesel, které lze zachytit, pokud klient, server = nebo bezpečná relace je ohrožena. V případě, že nepoužíváte přístupové heslo (což by se nemělo stát), stále nabízejí páry veřejných klíčů ochranu před ohroženými relacemi a servery.

84
john

Ve srovnání s uloženým seznamem (dlouhých a náhodných) hesel, uložený soukromý klíč SSH nabízí stejný security: věci jsou v bezpečí, pokud váš soukromý soubor zůstává soukromý.

Soukromý klíč je však mnohem více pohodlnější, a to prakticky (právě teď jej klienti SSH podporují okamžitě, na rozdíl od vlastního souboru hesel, který musíte použít s některými manuální kopírování a vkládání) a teoreticky (můžete použít stejný klíč pro každého hostitele, ke kterému se chcete připojit, zatímco seznam hesel bude lineárně narůstat s počtem kontaktovaných hostitelů, pokud znovu nepoužijete stejné heslo pro více hostitelů, což je - špatně).

15
Thomas Pornin

Záleží na tom, jaké hrozby považujete za.

Hlavním bodem ověřování pomocí veřejného/soukromého klíče není, aby vaše tajemství bylo vypuštěno, a to i vůči straně, které ověřujete. Z tohoto důvodu je použití klíčů lepší, protože svůj počítač nikdy neposíláte tajně.

Pokud je však hrozba, kterou považujete za místní, a nechcete-li své soukromé klíče chránit heslem, uložení jasného seznamu hesel je stejné jako uložení soukromých klíčů bez ochrany.

Z tohoto důvodu je užitečné chránit vaše soukromé klíče heslem a používat nástroje, jako je ssh-agent (pro větší pohodlí). V OSX může být toto také integrováno s KeyChain, takže možná nebudete muset dokonce odemykat soukromý klíč (na úrovni aplikace, pouze na úrovni démona zabezpečení), abyste jej mohli používat přes SSH (v podstatě KeyChain) a bezpečnostní démon se postará o ssh-agenta).

13
Bruno

Hlavní rozdíl mezi používáním soukromý klíč bez hesla a používáním heslo prostého text pro autorizaci SSH je autorizace něčím, co máte (váš soukromý klíč) nebo něco, co znáte (vaše uložené heslo). Jsou to různá plemena, ale je těžké říci, že jeden je nakonec lepší nebo bezpečnější.

Autorizace něco, co máte je pro útočníka obvykle obtížnější replikovat se z modré - je jednodušší si brutálně vynutit/uhodnout své jednodušší heslo, než replikovat váš klíč. Ale má to hlavní nevýhodu - nyní držení soukromého klíče v tajnosti se stává prvořadým. Pokud používáte něco, co znáte (zapamatované heslo), mělo by být snazší to takto udržet (alespoň teoreticky). Ale pokud si to musíte zapamatovat, pravděpodobně používáte něco, co není tak složité.

Je tedy na vás, abyste se rozhodli, co je pravděpodobnější - váš silný soukromý klíč bude odcizen nebo ne tak silné heslo uhádnuté (nebo získáno jiným způsobem).

Je tu jedna výjimka - pokud v otázce máte na mysli, že namísto použití soukromého klíče budete v tajném souboru ukládat opravdu dlouhá, složitá a náhodná hesla, pak pravděpodobně malý rozdíl mezi nimi ještě nějaký rozdíl (část jsem zmeškal, viz @ john odpověď na pěkný zápis k tomuto). V tom případě jsou oba něco, co máte , udržujte jej v tajnosti , ale pak se zeptejte sami sebe - proč to udělat v první řadě, pokud to je to, na co byly soukromé klíče určeny? v takovém případě byste měli zůstat se soukromými klíči.

10
Karol J. Piczak

Odkazovaný článek diskutuje o heslech zadaných v rámci ssh relace; Myslím, že to, a Richardovy komentáře, stojí za to se udržet, ale už ne věří v samotnou odpověď. (Stále preferuji veřejné klíče.)

Song, Wagner a Tian ukázali, že je možné zrychlit prohledávání heslem hrubou silou zhruba 50krát pomocí časovacích informací z ssh relace . Noack přehodnotil svou studii a zjistil, že SSH2 je rovněž náchylný k analýze načasování.

Útok vytváří dva předpoklady:

  • Heslo hash je k dispozici pro praskání hrubou silou.
  • Útočník může získat přesné časové značky na paketech odesílaných mezi hostiteli nebo jinak získat informace o časování.

Veřejné klíče jsou nejen pohodlnější, ale i bezpečnější proti určitým hrozbám.

8
sarnold

Pokud používáte klávesy „software“ (tj. Klíče uložené ve vašem adresáři .ssh nebo ekvivalentní), jste v podstatě na stejné úrovni jako ukládání hesel.

OpenSSH má nyní téměř slušnou podporu PKCS # 11, to samé je k dispozici v KiTTY (vidlice PuTTY), takže pro skutečné využití autentizace pomocí pubkey jděte na čipovou kartu. Pak je skutečný rozdíl od hesel. Softwarový klíčový soubor chráněný heslem lze replikovat stejným způsobem jako obyčejné heslo, zatímco čipová karta nemůže.

2
martin