Обліковий запис SSH-проксі може працювати без оболонки

Зберігайте переспрямування SSH доступним, вимикаючи сеанси оболонки, і розумійте межі примусового використання лише SOCKS.

Спокусливе налаштування — 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 може обмежити пари хоста й порту призначення, коли конкретний список відповідає вимозі. Це не загальна заборона з урахуванням розв'язання імен для кожної приватної мережі. Ширші обмеження адрес можуть вимагати відповідної мережевої політики хоста.

Налаштування облікового запису, ключа та включені налаштування сервера можуть додатково обмежити переспрямування. Загальна заборона переспрямування в іншому місці може прибрати можливість, яку цей фрагмент начебто дозволяє.

Використайте звичайну процедуру адміністрування сервера з шляхом відновлення, потім окремо оцініть дозволені та заборонені можливості. Бажаний результат — явні дозволи на переспрямування, а не інтерактивний вхід, випадково залишений доступним, і не проксі, вимкнене власним обмеженням.

Схожі статті