Unha conta de proxy SSH pode funcionar sen shell

A configuración tentadora é AllowTcpForwarding no. Desafortunadamente, tamén desactiva o reenvío que necesita un proxy SOCKS SSH local. O reenvío dinámico non é unha escotilla para saltar a política do servidor.

Para unha conta dedicada, OpenSSH separa varias capacidades. Un fragmento de política pode permitir o reenvío local e á vez bloquear as sesións de shell e de subsistema:

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

O manual do servidor describe MaxSessions 0 como unha opción que bloquea as sesións de shell, inicio de sesión e subsistema mentres permite o reenvío. Intégrea nunha conta autenticada existente; non é unha configuración de seguridade SSH completa.

Só reenvío non é só SOCKS

Un reenvío local fixo e unha solicitude SOCKS poden acabar pedindo ao servidor o mesmo tipo de conexión de destino. Permitir o reenvío local non garante que un cliente usase unha interface SOCKS concreta. Non describa a conta como impoñedora dun uso só SOCKS.

PermitOpen pode restrinxir pares de host e porto de destino cando unha lista concreta encaixa co requisito. Non é unha prohibición xeral consciente da resolución de nomes sobre cada rede privada. As restricións de enderezos máis amplas poden necesitar unha política de rede de host axeitada.

A configuración da conta, da chave e do servidor incluído poden restrinxir aínda máis o reenvío. Unha prohibición total de reenvío noutro lugar pode eliminar unha capacidade que este fragmento parece permitir.

Use o procedemento habitual de administración do servidor cun camiño de recuperación e despois avalíe por separado as capacidades permitidas e denegadas. O resultado previsto son permisos de reenvío explícitos, non un inicio de sesión interactivo deixado dispoñible por accidente nin un proxy desactivado pola súa propia restrición.