Форум

Иван, это не заблуждение, это man sshd_config
На моем сервере туннель не работает, как ему и положено.

Иван, вот так уже предметнее. Но чтобы хоть как-то успешно воспользоваться указанной, гм, "уязвимостью", пользователь должен знать пароль к mysql.
Тут возможны три сценария:
1) нам необходимо дать кому-то (например, разработчику, который докручивает решение) доступ на все директории сайта. В таком случае он легко читает файлик dbconn.php и получает пароль. Но мы ему и так дадим пароль на mysql и еще и в явном виде разрешим проброс порта в ssh, потому как это необходимо для работы (а некоторые странные люди даже выставляют mysql голой жопой в интернет для таких задач). Даже если мы запретим такому пользователю проброс портов, тунелирование или даже создадим виртуального ftp-пользователя, никто не помешает ему установить web-shell на сайт, который (внимание!) все равно будет работать с правами реального пользователя, от которого запущен апач, в данном случае это пользователь bitrix. Соответсвенно, риск "о господи, пользователь может пробросить порт! Ололо! Алярма!" считаем приемлемым, т.к. никакого повышения прав или несанкционированного доступа к чему-либо, кроме того, к чему и так есть доступ, не происходит. Условно говоря, давая кому-то ключ от входной двери, ты не паришься, сможет ли он открыть форточку.
2) нам необходимо дать кому-то доступ в какую-то конкретную директорию, например с каким-то модулем, для его доработки. Тут пользователь не может посмотреть файл dbconn.php, но в большинстве случаев ему все равно требуется доступ к базе и он его получит. Параноидальные режимы "надо же создать отдельного mysql-пользователя с доступом только в конкретные таблицы!" не рассматриваем. В реальности так никто не делает, практически никогда. Слишком невыгодное соотношение трудозатраты/безопасность.
3) вариация второго, но доступ только в папку с какими-нибудь картинками или еще чем-то подобным, когда нет доступа к директориям, где можно запускать php-файлы на исполнение и, соответственно, веб-шелл не запустить. Что ж, веб-шелла уже и так нет, пароль на mysql мы не сообщаем и узнать его пользователь не может (нет доступа к dbconn.php из-за chroot), остается только возможность пробросить порты и рассылать СПАМ от имени нашего сервера и делать подобные нехорошие штуки. Но т.к. этот пользователь - человек, которого мы нанимаем и, соответственно доверяем в какой-т остепени, а все действия оседают в логах (кто и когда подключался), то вероятность реализации данной уязвимости стремится к нулю. А т.к. риск это (грубо) - функция вероятности реализации угрозы потенциальной уязвимости и итогового влияния на актив, то при вероятности, стремящейся к нулю, риск также стремится к нулю.

Итак, если все же заморочиться оценкой рисков и посчитать ROI трудозатрат на реализацию ftp с виртуальными пользователями vs реализацию простого и быстрого способа (фактически - одна команда в ssh, также одна команда на отключение пользователя, всё, никаких больше телодвижений) способа реализации FTP-доступа, указанного выше, то мы приходим к выводам, что это вполне адекватный задаче способ с приемлемым уровнем риска. Итого, задача решается с минимальными трудозатратами, обеспечивая адекватный результат.
Я лично не вижу смысла (кроме как неиссякаемого перфекционисткого стремления к идеалу) заморачиваться чем-то еще.
Но спасибо за поднятые вопросы, они очень интересны, хорошая получилась беседа, полагаю, что наша беседа пригодится читающим, каждый сделает свои выводы исходя из своих приоритетов и задач.

Если у вас совсем не получается под фтп зайти, в консоли  выполните proftpd и он выдаст ошибки. Если ошибок нет, необходимо проверить порт 21

s909, proftpd точно установился? /etc/proftpd/ есть? Конфиги внутри лежат?

А вообще я лично использую vsftpd, в том числе и на bitrixvm. Работает замечательно.