Соблазнительная настройка — AllowTcpForwarding no. К сожалению, она также отключает перенаправление, необходимое локальному SSH SOCKS-прокси. Динамическое перенаправление не является лазейкой в обход политики сервера.

Для выделенной учётной записи OpenSSH разделяет несколько возможностей. Фрагмент политики может разрешить локальное перенаправление, блокируя сеансы оболочки и подсистем:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

Руководство сервера описывает MaxSessions 0 как настройку, блокирующую сеансы оболочки, входа и подсистем, но разрешающую перенаправление. Встройте её в существующую аутентифицированную учётную запись; это не полная конфигурация безопасности SSH.

Только перенаправление — не только SOCKS

Фиксированное локальное перенаправление и запрос SOCKS в итоге могут запросить у сервера соединение к тому же типу назначения. Разрешение локального перенаправления не гарантирует, что клиент использовал определённый интерфейс SOCKS. Не описывайте учётную запись как принуждающую использовать только SOCKS.

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

Настройки учётной записи, ключа и включённые настройки сервера могут дополнительно ограничить перенаправление. Общий запрет перенаправления в другом месте может убрать возможность, которую этот фрагмент, по-видимому, разрешает.

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

Похожие статьи