Як обмежити переадресацію порту ssh, не відмовляючи?


5

Припустимо, я створив обліковий запис, оболонка входу якого насправді є скриптом, який не дозволяє інтерактивне вхід, а дозволяє лише дуже обмежений, певний набір команд віддалено виконувати.

Тим не менш, sshдозволяє користувачеві цього облікового запису пересилати порти, що є діркою.

Тепер суть полягає в тому, що я дійсно хочу, щоб цей обліковий запис створив конкретну конфігурацію переадресації портів, коли sshсеанс встановлений. Але конфігурувати довільну переадресацію порту повинно бути неможливо.

(Це прийнятне рішення, якщо дозволена конфігурація переадресації портів безумовно встановлена ​​як частина кожного сеансу.)


Якщо за пару днів ніхто не висунеться, я прийму власну відповідь. І, можливо, попрацюйте над цим.
Каз

Якщо ви будете тримати його неприйнятим / відкритим протягом деякого часу, тоді ви отримаєте трохи більше уваги. Деяким людям подобається проводити вихідні десь в іншому місці, ніж SO :)
Сампо Саррала

Моєю оригінальною відповіддю був запропонований патч, але існуючі функції в OpenSSH роблять цю роботу.
Каз

На жаль, це належить до сервера за замовчуванням, чи не так! Неважко забути, що "суперпользователь" тут не означає "корінь" або "системдмін".
Каз

Відповіді:


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. Однак вирішення проблеми полягає у використанні нешкідливого, неіснуючого або неможливого імені хоста, такого як порожній рядок. Конкретно, acceptopen = ": 1234" робить трюк.

Аргумент "будь-який" може бути використаний для видалення всіх обмежень та дозволу на будь-які запити переадресації. Аргумент "немає" може бути використаний для заборони всіх запитів на переадресацію. За замовчуванням всі запити на переадресацію портів дозволені.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.