Първо, ЧНГ.
Това би означавало, че Линукс-а ми дефакто става толкова защитен колкото и Windows-а защото пробие ли някой Windows-a ще достигне и до ключа за Linux-a. Вярно, е че има и keyphrase, но той само забавя.
Забавя, забавя, ама колко да забавя. John the ripper примерно на моята машина (quad-core phenom2, 3.2GHz) го троши с около 130 хиляди опита в секунда. Това е доста малко. Абсолютно непрактично за bruteforce-ване от страна на един индивид или някаква малка/средно голяма организация. Ако си избереш хубав passphrase, мисля нещата ще са наред.
Затова се питах има ли начин системата да работи както си работи без ключ и върху криптирането което има когато се ползва парола да се насложи това за ключ. Тоест примерно имам connection криптирана с AES примерно и с парола и върху това да може да се подсили с вторично криптиране например с 3DES което е да речем вече зависещо от ключа.
Мисля, че малко омесваш понятията. SSH е чуден протокол, доста комплексен. Целите, които гони са няколко, не само конфиденциалност на връзката (която се постига със симетрична криптография, като например AES), но и защита против MiTM атаки (която се постига чрез HMAC стойности към всеки пакет) - и в случая когато ползваш ключове - цели и сигурна автентикация. Тези трите са съвсем отделни неща. Конкретният проблем с автентикацията няма да се реши ако решиш да криптираш връзката с още един симетричен алгоритъм с различен (споделен) ключ. Първо, ако толкова държиш да си имаш още един механизъм за автентикация със споделен ключ, няма нужда да криптираш връзката с него - има си challenge-response механизми. Но и при това положение, твоят проблем не се решава - ако някой ти хакне windows машината, нищо не му пречи да ти инсталира keylogger и да разбере това което въвеждаш. За проблемът, който бориш има други решения - примерно онези token-и на RSA Security, или пък някаква биометрия. Всичко това струва пари и време и надали целта оправдава средствата в твоя случай.
За съжаление не мога да си позволя излишен разход на RAM памет. Добре де аз по друг начин но все пак мисля, че намерих кое къде е. Принципно къде може да се намери хубав пример за това как се прави jail от който ама наистина няма как да се излезе?
chroot jail-а на практика не води до особено повишени изисквания към RAM паметта. Към мястото на харддиска евентуално, защото може да се наложи да копираш определени библиотеки или изпълними файлове в jail директорията.
chroot също така никога не е бил замислян с идеята да бъде security мярка, странно колко хора вярват в обратното. Ако се сдобиеш с root права, ще "излезеш" и това е почти неминуемо. Ако става въпрос за някаква публична услуга те съветвам да използваш дистрибуция, която интегрира някакво MAC решение като SELinux или Apparmor относително успешно (последното за да си спестиш страшно много усилия). Няма да минеш без доста пипане, особено ако става въпрос за уеб приложение, но това е далеч по-добро решение. Идеята да не можеш да ходиш извън някаква директория, не е много добра по отношение на сигурността - защото сама по себе си не те ограничава какво _можеш_ да правиш в рамките на jail-а. И пак казвам - има доста начини да излезеш оттам сдобиеш ли се с root-ски права. Най-простият е да mount-неш procfs някъде - оттам можеш да ходиш във всяка текуща директория на всеки процес, без значение дали е jail-нат или не.