Un compte de proxy SSH pot funcionar sense shell

La configuració temptadora és AllowTcpForwarding no. Malauradament, també desactiva el reenviament que necessita un proxy SOCKS SSH local. El reenviament dinàmic no és cap escletxa per saltar-se la política del servidor.

Per a un compte dedicat, OpenSSH separa diverses capacitats. Un fragment de política pot permetre el reenviament local mentre bloqueja les sessions de shell i de subsistema:

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

El manual del servidor descriu MaxSessions 0 com a blocador de les sessions de shell, d'inici de sessió i de subsistema mentre permet el reenviament. Integreu-lo en un compte autenticat existent; no és una configuració de seguretat SSH completa.

Només reenviament no és només SOCKS

Un reenviament local fix i una petició SOCKS poden acabar demanant al servidor el mateix tipus de connexió de destinació. Permetre el reenviament local no garanteix que un client hagi utilitzat una interfície SOCKS concreta. No descriviu el compte com a aplicador d'un ús només de SOCKS.

PermitOpen pot restringir parells d'amfitrió i port de destinació quan una llista concreta encaixa amb el requisit. No és una prohibició general conscient de la resolució de noms sobre cada xarxa privada. Les restriccions d'adreces més àmplies poden necessitar una política de xarxa d'amfitrió adequada.

La configuració del compte, de la clau i del servidor inclòs poden restringir encara més el reenviament. Una prohibició total de reenviament en un altre lloc pot eliminar una capacitat que aquest fragment sembla permetre.

Utilitzeu el procediment habitual d'administració del servidor amb un camí de recuperació i després avalueu per separat les capacitats permeses i denegades. El resultat previst són permisos de reenviament explícits, no un inici de sessió interactiu deixat disponible per accident ni un proxy desactivat per la seva pròpia restricció.