Díky za ten hashing, v Debianu je defaultně zapnutý a já se divil, proč mi přestalo fungovat doplňování hostitelů. Hned jsem to vypnul :).
Nevýhodou na druhé straně může být zneužitelnost sdíleného soketu místním superuživatelem, neměli bychom tedy tuto vlastnost zapínat na počítači, kde superuživateli plně nedůvěřujeme.
No, pokud má root zlé úmysly, věděl bych o mnoha jednodušších způsobech pwnování SSH než je čekání na nějaký socket.
> Hashování souboru known_hosts
Security through obscurity? Únik soukromého klíče je sakra průšvih, snažit se to maskovat tím že neřeknu k jakému serveru patří je docela zoufalé. Nehledě na to, že když někdo může získat ~/.ssh/id_[dr]sa, ten ~/.bash_history už pro něj takový problém nebude.
Únik klíče samozřejmě průšvih je, ale stává se to lidem i s klíči od bytu a proto si na ně většina rozumných lidí nedává visačku s adresou.
Security by obscurity je v reálném životě legitimní technika. Ta nejzákladnější, přirozená, levná a často účinnější než opravdové zabezpečení. Jen my od počítačů to považujeme za zbabělost a workaround. Malé poučení o oficiální bezpečnostních třídách trezorů (DIN i NBÚ): dělí se podle doby, jakou potřebujete na jejich násilné otevření.
(A pointa direktivy IGNORE je v tom, že ignorované příkazy neukládá do zmiňovaného souboru.)
mam stejny dojem. Dalsi misto, kde je mozne vycist, na jake servery se (asi) spojuji muze byt napr. ~/.ssh/config. A ten uz predpokladam zabezpecit nejde (krome prav)
Smyslem toho hashování je hlavně získat dostatek času na odstranění veřejných klíčů na postižených serverech. Rozhodně by nemělo jít o bezpečnostní techniku, která by nahrazovala cokoliv jiného.
Dekuji za serial, znacne rozsiril me predstavy o tom, co vsechno je se ssh mozne a jak si nekolik veci ulehcit.