Как ограничить переадресацию порта ssh, не отрицая это?


5

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

Тем не менее, sshпозволяет пользователю этой учетной записи переадресовывать порты, что является дырой.

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

(Это приемлемое решение, если разрешенная конфигурация переадресации портов безоговорочно устанавливается как часть каждого сеанса.)


Если через пару дней никто не выступит, я приму свой ответ. И, возможно, начать работать над этим.
Каз

Если вы оставите его непринятым / открытым в течение некоторого времени, вам будет уделено немного больше внимания. Некоторые люди любят проводить выходные где-то еще, чем SO :)
Сампо Саррала

Моим первоначальным ответом был предложенный патч, но существующие функции в OpenSSH делают свою работу.
Каз

Ой, это относится к серверной ошибке, не так ли? Легко забыть, что «суперпользователь» здесь не означает «root» или «sysadmin».
Каз

Ответы:


7

Оказывается, в OpenSSH есть функция для ограничения -Lстилей, открываемых на стороне сервера. Функция доступна двумя способами.

  1. В файле конфигурации сервера есть PermitOpenопция. Эта опция может использоваться для указания хостов и портов, для которых могут быть установлены пересылки. Эта опция может использоваться внутри Matchблока, поэтому она может быть ограничена пользователем, группой или именем хоста или шаблоном IP-адреса.

  2. В authorized_keysфайле параметры могут быть связаны с определенным ключом. Есть permitopenопция, которая работает аналогично конфигурации сервера.

Примечания / Ограничения:

  • Эта опция AllowTcpForwardingотключает всю переадресацию в обоих направлениях, предотвращая настройку прослушивающих портов на сервере, а также активную переадресацию.

  • Нет PermitOpenконтроля доступа для -Rстилевых соединений. Это, наверное, хорошо. Это означает, что пользователи могут использовать sshдля открытия различных непривилегированных портов для прослушивания на сервере. Там, где они подключаются на другой стороне SSH-соединения, проблема клиента. Если мы ограничим переадресацию в -Lнаправлении, у пользователя не будет возможности использовать эти -Rпорты (по крайней мере, не через ssh, если этот пользователь не сможет создать произвольный интерактивный сеанс).

  • Кажется, не существует способа создать пустой список разрешенных открытий, чтобы пользователи не могли устанавливать какие-либо -Lстилистические соединения. Однако обходной путь - использовать безопасное, несуществующее или невозможное имя хоста, такое как пустая строка. Конкретно, permitopen=":1234"делает трюк.


Поскольку я могу жить без точного контроля доступа -R, это работает для меня.
Каз

0

Похоже, не существует способа создать пустой список разрешенных открытий, чтобы пользователи не могли устанавливать какие-либо подключения в стиле -L. Однако обходной путь - использовать безопасное, несуществующее или невозможное имя хоста, такое как пустая строка. Конкретно, allowopen = ": 1234" делает свое дело.

Аргумент «any» может использоваться для снятия всех ограничений и разрешения любых запросов на пересылку. Аргумент «none» может использоваться для запрета всех запросов на пересылку. По умолчанию все запросы на переадресацию портов разрешены.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.