Opravdu pomůže přihlašování bez hesla s pomocí rsa? Začínám mít pocit, že to je Krčmářova oblíbená pověra :(
Řekněme, že budu mít server A a diskový pole B. A využívá B tak, že se namapuje pomocí SSHFS. Příkaz pro připojení je v autofs, pro přihlášní se použije cert a klíč na A. Útočník ovládne A. V té chvíli má automaticky konzolu na B, protože má privátní klíč, který B zná na stroji, se kterým je ten klíč svázaný.
Pokud se A nepřihlašuje s hodně velkýma omezeníma (uživatel není v sudoers, nemá root práva, smí jenom na konkrétní data, ...), tak je rázem infikovaný i B...
Ano, pomůže, ale nesmíte ignorovat požadavek na PIN při generování klíče.
Pak se přihlásíte něčím, co máte (klíč) a něčím, co znáte (PIN). Obojí se útočníkovi získává mnohem hůř, než jen jedno. Samotné heslo je nejhorší (může někde uniknout), klíč je na tom přece jen líp.
Záleží taky na tom, kdo to používá. Pokud je to skutečně BFU, můžete potkat až nepochopitelné chování.
Pomůže to, pokud klíče neleží na tom serveru. Typicky se tenhle malware šíří v případě, že uživatel používá na dvou serverech stejná hesla a přihlašuje se jimi i pomocí SSH. To není rozhodně neobvyklé, podle mých zkušeností používá většina adminů hesla, takže pokud se přihlásí ze stroje na stroj a na tom prvním ten malware je, bude za chvíli i na tom druhém. Při použití klíčů, které leží na správcově desktopu, to nehrozí. Navíc je možné vypnout přihlašování heslem úplně (což já všude mám a doporučuji to) a pak není možné ani hesla hádat a někudy se do systému dostat.
Druhý případ je to zmiňované propojení mezi servery, tam samozřejmě pomůže výrazně omezit práva daného uživatele. Není důvod, aby uživatel přistupující jen k souborům, měl přístup na terminál a do celého systému. Pokud na mých serverech uživatel někam potřebuje něco nahrávat, tak ho zavřu v chrootu a omezím na nutné minimum.
Ale pozor! I když má správce klíče u sebe, ale přihlašuje se _přes_ napadený stroj pomocí forwardu ssh-agenta, tak malware může být schopen toto spojení použít a získat oprávnění i na tom dalším stroji. Je lepší proto místo forwardu ssh-agenta používat ProxyCommand nebo ProxyJump.