Kdyby člověk chtěl, asi nějaké důvody najde. U klíče mi zase vadí, že nejsi schopný vynutit, že klíč je šifrovaný a že se třeba nepoužívá agent, tj. nastavit nějakou policy, jediná rozumná možnost je mít HW token, kde ten klíč. To mluvím hlavně o firemním prostředí.
Tohle je asi nejzásadnější nevýhoda ověřování pomocí klíčů a je to asi taky ten hlavní důvod proč ho některé firmy nechtějí používat.
Pokud mají kontrolu nad strojem, můžou ssh-agent zablokovat. A generovat sadu klíčů na serveru a nedovolit uživatelům si nahrávat vlastní. Ale tak jako tak, co mi přesně brání si udělat ssh_company.sh, který prostě udělá něco stylem echo "username\npassword" | ssh? 
To jsou ty snahy o zvýšenou bezpečnost, které vedou ke žlutým papírkům s heslem nalepeným na monitoru a pracovním čase spáleném bojem mezi IT a zaměstnanci.
vygeneruješ šifrovaný klíč, ale už nezajistíš, že si ho uživatel nedešifruje a nebude mít v plaintextu. Jak se blokuje ssh-agent, když si uživatel může do socketu v env SSH_AUTH_SOCK dát jakoukoliv aplikaci (jo jasně, můžeš to nějak hardcodovat, vyměnit ssh klienta za vlastního atd.), to ale pořád znamená, že ta policy se vynucuje velmi obtížně.
Pokud to heslo bude OTP kód z aplikace, to echo ti moc nepomůže.
Tobě to připadá jako nesmyslný boj, já zase zažil až příliš ukradených ssh klíčů, protože si je nějaký program přečetl z home složky uživatele a donutit uživatele, aby spustit pod sebou na linuxu nějaký program (i blbý pip install) je dneska strašně snadné nebo když se kdejaká věc instaluje přes curl https://... | bash.
Ten linux to prostě nemá dobře vyřešené, dá se to nějak předělat, ale to znamená to extra vymyslet pro každou distribuci a pravidelně to aktualizovat. Nejsem zastánce přepisování kódů nebo neustálému zadávání master hesla pro každé ssh sezení.
19 Odpovědí
5479 Zhlédnutí