Как я могу перенаправить пользователей SSH к другому входу в систему SSH?
У меня есть человек, которому будет нужен доступ к моему серверу SSH, но я хочу, чтобы у них был ограниченный доступ к программам. Все, что они должны использовать, является ssh, для входа в систему в другой сервер. Мой сервер является точкой доступа к другому серверу. Я не хочу, чтобы этот пользователь запустил программы кроме ssh программы, они должны войти в другую сеть.
Идеально, когда они входят в систему, они были бы перенаправлены к другому входу в систему SSH и не имели бы любую другую непосредственную опцию сделать что-либо еще.
Ни у каких пользователей SSH нет корневых полномочий.
Как я мог бы смочь настроить это? Я думаю, что могу сделать это с их bashrc файлами. Я запишу вторичный сценарий входа в систему, который выполняется, когда они входят в систему. Существует ли способ для пользователя войти в сервер SSH и проигнорировать их bashrc файл на входе в систему? Существует ли лучший способ, которым я должен рассмотреть?
4 ответа
Рассмотрите использование a ForceCommand директива в sshd_config. Например, я использую их для принуждения групп пользователей к ряду серверов:
Match Group group1
ForceCommand ssh -t group1.fqdn
Match Group="*,!local,!group2,!root"
ForceCommand ssh -t group3.fqdn
Вы могли использовать:
Match User foo
ForceCommand ssh -t target-host
Вы думавший отредактировать bashrc файл. Я смотрел бы на ограничение их доступа ко всем командам удара кроме ssh таким образом, они могут. Этот ссылка имеет хорошую информацию.
Другая мысль состоит в том, чтобы установить ssh, проходят через туннель без доступа к входу в систему. Этот ссылка могла бы быть полезной также. Это могло бы быть легче настроить.
Просто установите оболочку входа в систему пользователя на сценарий оболочки вместо удара или sh, содержащего ssh синтаксис к второй конечной точке. Все логины, если они явно не определяют оболочку с-s в ssh синтаксисе, перенаправили бы, как Вы запросили.
я могу выйти из ограничений BASHRC различными методами. Если Вы ожидаете, что они будут злонамеренными, удостоверяются, что они не могут указать альтернативную оболочку на входе в систему.
пользователь Прерывания sigint, таким образом, они наклоняют Ctrl + C и проверяют выход ssh для кода выхода 0, иначе выходят полностью или повторяют неограниченно долго. Ваш выбор.
Можно сделать это несколько прозрачно, вынудив пользователя использовать a ProxyCommand локально, рассматривая Ваш собственный сервер как хост оплота SSH.
На Вашем сервере (оплот), ограничьте пользователя nc следующим образом в sshd_config:
Match User restricted_usr
ForceCommand nc -w 600 restricted_usr_vm 22
На клиенте (принятие OpenSSH) в ~/.ssh/config:
Host myserver
ProxyCommand ssh bastion nc -w 600 restricted_usr_vm 22
(Пользователи Windows могут использовать прокси ssh через PuTTY при помощи PuTTY plink).
Хотя, благодаря Вашему ForceCommand, Я вполне уверен, команда ssh проигнорирована; ProxyCommand ssh bastion I am a bannana должен иметь тот же эффект. Прямое подключение (недостаток ProxyCommand) от пользователя приведет к необработанному дампу SSH к restricted_usr_vm.
Как отмечено в комментарии к другому ответу здесь, ForceCommand сделает его очень трудно для управления ключевым доступом SSH к хосту оплота. Я могу думать о двух легких решениях: (1) Установка ключ SSH без пароля для того пользователя на оплоте, который предоставляет доступ к целевому узлу и имеет crontab того пользователя на выполненном оплоте scp restricted_usr_vm:.ssh/authorized_keys ~/.ssh/ или (2) Создают веб-форму (как GitHub), чтобы позволить загружать тот файл. (3) NFS может также работать, но я не так люблю его потому что .ssh каталог мог стать поставленным под угрозу кем-то с корнем (или тот же UID) в любой системе, которая монтирует его.
Я отправил очень похожий ответ (с большим количеством детали о ProxyCommand) к очень похожему Имени пользователя вопроса о ServerFault базирующийся прокси SSH.
Мне нравится это намного лучше, чем ForceCommand ssh -t restricted_usr_vm потому что это имеет дело с тайм-аутами лучше и ssh -t является довольно неуклюжим (и, возможно, к настоящему времени в прошлом иногда ненадежным). Я также предполагаю это вещи как scp не будет работать через этот метод, в то время как они будут работать отлично через ProxyCommand.