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 може да ограничи двойките хост и порт на дестинацията, когато конкретен списък отговаря на изискването. Това не е обща забрана, съобразена с разрешаването на имена, за всяка частна мрежа. По-широки ограничения на адреси може да изискват подходяща мрежова политика на хоста.

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

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

Подобни статии