Игорь

Никак. Нет такого прокси сервера для ssh, чтобы он слушая на шлюзе по домену на который Вы идете маршрутизировал бы трафик.
Я вижу 4 варианта:
1. Купить дополнительных ip и навесить их на виртуалки, чтобы у каждой был свой адрес. Каждый домен делигировать на соответствующий адрес. Это самое простое и удобное решение.
2. На контейнерах подняты "серые" адреса, в /etc/hosts хост системы прописаны соответствия доменов разработчиков этим адресам. Соответственно пользователь по ssh сначала заходит на Вашу хост систему (сервер), а оттуда уже в контейнер по "серой" сети. Очень не элегантно, но дешево и просто.
3. Разрулить все iptables, развесив правила на разные порты. Постучались на 2222 порт попали на первую виртуалку, постучались на 3333 порт попали на вторую. Настраивается легко, из неудобств нестандартные порты.
4. Если есть офис, то как-то увязать "серую" сеть контейнеров за нодой, с сетью с офисе. Обычно такое делается средствами VPN, ну и поднять в офисе DNS где делигировать доменные имена на "серые" адреса. Тут как бы и схема не отказаустойчева, так как сеть в офисе упадет и подключиться уже не смогут к контейнерам привычным способом и подключаться надо из сети офиса ( но если у Вас и так все в ней работают, то это только плюс).

Да, надо использовать ключи, это надежнее паролей, так как не перехватывается.
Если же все-таки хотите использовать пароль заведите себе какую-то хранилку для этого, например keepass (очень удобно и вводить уже можно будет простым копированием).

Делаете chroot-окружение. Можно для этого использовать тот же debootstrap.
Туда монтируете /proc, /sys. Копируете файлы /etc/{passwd,shadow,group,gshadow}. Монтируете директорию к которой надо предоставить доступ пользователю в chroot. И через /etc/ssh/sshd_config указываете чтобы он при подключении по ssh попадал в chroot-окружение.

Вам надо не последние действия смотреть, а что именно произошло разбираться.
Проверить iptables:
iptables-save
Проверить слушает ли вообще ssh-демон:
netstat -ntpua |grep ssh
Смотреть логи.