Az ssh-nál az nem jelent problémát. Ha bruteforce-olnak akkor az autentikációs protokoll részt piszkálják csak (sőt leginkább csak a jelszót próbálják kitalálni). Ez azt jelenti, hogy legfeljebb az RSA és DSA titkosítások játszanak szerepet. Ezek csak a beléptetéskor/kulcsegyeztetéskor kellenek. A session titkosító az ami lehet 3des, blowfish, aes, cast, arcfour stb. ez az ami a már felépült kapcsolaton az adatforgalmat viszi és az a szerepe, hogy ne tudja harmadik fél a forgalamat lehallgatni. Az a jó, hogy a *kliens* gépen az ssh.conf-ban szerverenként külön meg tudod adni, hogy milyen titkosítást preferáljon. Olyan gépre amit *te* a *kliensről* lokális hálón érsz el, gyenge titkosítást állíthatsz be. A gyenge nem azt jelenti, hogy wep szintű, 2 perc alatt egy géppel megtörhető, csak annyit, hogy tudományosan ismert a brute force keresésnél valami előnyösebb algoritmus, és egy erős clusterrel belátható időn belül megfejthető a kulcs. Az átlag script kiddie nem tud ezekkel sem mit kezdeni. Ha tudna, akkor az openssh fejlesztők azonnal ki is vették volna a lehetőségek közül. Egyébként az AES128 is gyorsabb a 3des-nél, de senki nem gondolja úgy, hogy gyengébb lenne, sőt a jelenlegi tudásunk szerint valamivel még erősebb is.
Szóval visszatérve a lényeg az, hogy ha kivülről éred el a gépet, akkor a kinti *kliensen* mást állítasz be és akkor erősebb titkosítást, mondjuk AES256-ot fog használni. Gondolom úgysem 1Gbit-es a netelérésed, tehát ott nem kell spórolni a cpu terheléssel. Sőt 1-2Mbit esetén még simán megéri a tömörítést is bekapcsolni.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...