Удаленный доступ с x2go: nx по требованию

Когда надо удаленно обратиться к какой-нибудь из моих машин я в силу природной лени использую x11vnc. Всем хорошо, но не нравится запускать сервер. Когда-то давно очень мне нравился nx. Работает очень шустро. Но тоже, надо запускать сервер, а это мне не нравится, лишние открытые порты и пожираемые ресурсы не приводят ни к чему хорошему. Думаю, где-то с год как точно слышал о x2go, но попробовать никак не доходили руки. Тут таки приперло (через x11vnc отвратно работала клавиатура, да и скорость не радовала) и я совершил титанические усилия по установке и настройке, которые в генту сводятся к следующему:

1. На сервере:

Устанавливаем:

emerge x2goserver

Запускаем базу:

rc-config start postgresql

Создаем схему в базе:

/usr/share/x2go/script/x2gocreatebase.sh

Разрешаем доступ для пользователей группы users:

echo "%users ALL=(ALL) NOPASSWD: /usr/bin/x2gopgwrapper" >> /etc/sudoers

Стартуем сервер:

rc-config start x2goserver

2. На клиенте:

emerge x2goclient

x2goclient

Работает все очень шустро, глюков похожих на x11vnc не наблюдается, хотя есть и свои замороты. Интерфейс клиента позволяет на время забыть о опциях командной строки. И главное, на сервере у нас по прежнему открыт только ssh, что не может не радовать.

denyhosts вешает ssh!

Да, именно так.

Столкнулся тут, что после множества ошибок в работе операционки в период сбоя с памятью стал намертво вешаться sshd при обращении, притом вешаться со 100% нагрузкой на процессор.

Поскольку не люблю сложных решений, сделал несколько раз emerge -e world, однако это как-то не решило проблему.

Пришлось копаться. Копание делал с strace с опцией -p (цепляемся к корневому процессу sshd) и -f (следим за fork-ми). До этого так не извращался. Анализ вывода strace показал, что denyhosts портит файл /etc/hosts.deny, а sshd видимо не в состоянии прилично это обработать и вешается. Уж не знаю, ошибка ли это openssh, и стоит ли писать об таком типе атаки (ведь потенциально, эту строку можно сознательно заставить вставить в /etc/hosts.deny назначив себе такое имя хоста). Возникло все это от случайных сбоев в памяти, и реальную причину такого поведения denyhosts я пока не успел выяснить (отпишусь сюда же, когда доведу до конца). Есть подозрение, что есть какие-то завязки на версии python'а, и сбои, которые у меня с ними были. Пока пришлось подредактировать /etc/hosts.deny и отключить denyhosts на время разбирательств, что печально.