Антон Шигаев, не понимание идет вообще неизвестно откуда ибо протокол общения ssh, а значит /home/user/.ssh/authorized_keys это верно)
в этом файле должен быть публичный ключ, права 400 и owner - тот самый пользователь. Pavel Zamyatin правильно указал в комментариях про отладку и ссылку на мануал. Стоит еще посмотреть можно ли этому пользователю вообще соединяться по ssh. может еще не корректно создан public key, но в мануале все есть
Berkutman, Таблицу маршрутизации все-равно не получится изолировать. Проблема просто имеет другой характер. Пока это один сервер таблица все-равно будет в том или ином виде. Будет таблица маршрутизации на хосте, будет таблица маршрутизации на роутере. То как она управляться будет - дело десятое
Berkutman, Диск он и в Африке диск. Как к нему коннектиться дело десятое. Виртуалки сама по себе во внешку не сможет смотреть - ip-шников не хватит. Вртуалтка все-равно за Nat и циской так что dns в помощь, скорее всего. Таким образом можно раскидать все по портам на доменах и не мучаться даже с центральным вебсервером
Berkutman, как мило. особенно учитывая что среднестатистической панели управления для аутентификации через LDAP требуется отдельный Identity Server типа Keycloak или wso2. И немного непонятно почему у виртуалок /16, а не /32) - планируется blue-green deployment на одном сервере?) Вообще если один сервак то вся идея изначально гиблая ибо лег сервер и все клиенты пока-пока
Berkutman, на схеме сразу не хватает локальной сети пользователя, vpn соединений и т.п. вебсервер с роутингом вторичен (это просто http роутинг, скучно и просто), а аутентификация - куда (виртуалка, панель? и если да то какая?)
Berkutman, еще раз - я хочу услышать для чего или почему) то что хочется это следствие. Это все решаемо, тем же terraform + обвязками, но абсолютно дикая история по тому что у вас машина быстро кончится (хотя если так пара-тройка пользователей то ок)
