Нераспознанный тип: для длины строки даты [закрыто]

Проблема с обработкой этого путем изменения оболочки входа, как в вашем примере, заключается в том, что когда пользователь подключается к sshd в основной сети тогда, даже если вы заставите их оболочку работать в другом пространстве имен, но их перенаправление портов все равно будет работать в пространстве имен сети по умолчанию.

Предлагаемое мной решение также касается перенаправления портов в пространство имен, а также в оболочку. Вероятно, это ограничено использованием локальных учетных записей, поскольку аутентификация в удаленной системе по сети (NIS, SMB и т. Д.), Вероятно, не будет работать, потому что этап аутентификации будет выполняться из сетевого пространства имен.

Мне нужна была оболочка и перенаправление портов для работы в целевом пространстве имен без создания сети / маршрутизации между пространством имен по умолчанию и пространством имен .

Вот несколько методов / инструментов для достижения этой цели:

xinetd - Спасибо Стефану Шазеласу за указание на это. Для одного или статического количества пространств имен и пересылки к ним xinetd кажется лучшим вариантом. например файл /etc/xinetd.d/sshd-netns-foo

service sshdnetns
{
    type            = UNLISTED
    socket_type     = stream
    protocol        = tcp
    port            = 222
    wait            = no
    user            = root
    server          = /sbin/ip
    server_args     = netns exec NameSpaceName /usr/sbin/sshd -i
}

socat - для нескольких пространств имен, в которых пересылка в них должна запускаться / останавливаться независимо socat подходит. Запустите это в пространстве имен по умолчанию:

socat tcp-listen:222,fork,reuseaddr \
      exec:'ip netns exec NameSpaceName /usr/sbin/sshd -i',nofork

ncat - если socat недоступен, то ncat ( в моем RHEL-ящике nc ) может выполнить эту работу. Обратной стороной ncat является то, что sshd подключен к ncat ] через канал, а не напрямую в сокет, поэтому sshd не может видеть IP-адрес клиента со всеми следующими последствиями. Вы также запускаете дополнительный промежуточный процесс ncat .

ncat --keep-open --sh-exec "exec ip netns exec NameSpaceName /usr/sbin/sshd -i" -l 222

и, возможно, другие инструменты.

Это принимает SSH-соединения в пространстве имен по умолчанию на настраиваемом порту 222, и для каждого соединения запускается один раз sshd -i внутри целевого пространства имен.

Это решило проблему для меня, но у вас также есть требование ограничить количество пользователей, которые могут входить в каждое пространство имен. Создайте конфигурацию sshd для конкретного пространства имен:

mkdir -pv /etc/netns/NameSpaceName/
cp -Rp /etc/ssh /etc/netns/NameSpaceName/

Добавьте элементы управления доступом к каждому файлу sshd_config , например по умолчанию / etc / ssh / sshd_config :

AllowUsers user1 user2

...и в / etc / netns / NameSpaceName / ssh / sshd_config

AllowUsers restrictedUser1 restrictedUser2

... также посмотрите на директивы AllowGroups

, теперь заново создайте пространство имен, чтобы привязки dir вступили в силу

Мои краткие тесты показывают, что контроль доступа пользователей работает должным образом, но я не особо часто им пользовался, так что вы должны его проверить.

Я попытался поместить отдельные файлы / etc / passwd , / etc / shadow и / etc / group в / etc / netns / NameSpaceName / за отдельный список пользователей, но в моем быстром тесте это не сработало: useradd test внутри пространства имен не работает.

Примечания:

Если вам не нравится настраиваемый порт, вы можете использовать двойной домашний, например macvlan или просто добавьте еще один IP-адрес и прослушивайте порт по умолчанию на выделенном IP-адресе.

Вся аутентификация, оболочка, подсистема, переадресация портов и т. Д. Обрабатываются sshd , поэтому мне не нужно ничего взламывать.

У него есть недостаток при запуске sshd -i таким образом, прочтите man sshd найдите параметр -i . Вы можете легко решить эту проблему, запустив полный рабочий день sshd внутри пространства имен и изменив демон пересылки на что-то вроде этого:

nc --keep-open --sh-exec "exec ip netns exec NameSpaceName nc localhost 22" -l 222

Интересно, могут ли монтироваться и / или пользовательские пространства имен (в дополнение к сетевым пространствам имен) можно использовать, чтобы решить эту проблему более аккуратно. У меня нет опыта работы с ними.

Наверное, есть более эффективные способы добиться этого, мне было бы очень интересно, что придумают другие.