Uma conta de proxy SSH pode funcionar sem shell

A configuração tentadora é AllowTcpForwarding no. Infelizmente, ela também desativa o encaminhamento de que um proxy SSH SOCKS local precisa. O encaminhamento dinâmico não é uma brecha em torno da política do servidor.

Para uma conta dedicada, o OpenSSH separa várias capacidades. Um fragmento de política pode permitir o encaminhamento local enquanto impede sessões de shell e de subsistema:

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

O manual do servidor descreve MaxSessions 0 como uma opção que impede sessões de shell, login e subsistema enquanto permite o encaminhamento. Integre-a numa conta autenticada existente; não é uma configuração de segurança SSH completa.

Apenas encaminhamento não é apenas SOCKS

Um encaminhamento local fixo e um pedido SOCKS podem acabar por pedir ao servidor o mesmo tipo de ligação de destino. Permitir o encaminhamento local não garante que um cliente usou uma interface SOCKS específica. Não descreva a conta como impositora de um uso apenas SOCKS.

PermitOpen pode restringir pares de anfitrião e porta de destino quando uma lista específica se adequa ao requisito. Não é uma proibição geral consciente da resolução de nomes em cada rede privada. Restrições de endereços mais amplas podem exigir uma política de rede de anfitrião adequada.

As definições da conta, da chave e do servidor incluído podem restringir ainda mais o encaminhamento. Uma proibição total de encaminhamento noutro local pode remover uma capacidade que este fragmento parece permitir.

Use o procedimento habitual de administração do servidor com um caminho de recuperação e depois avalie separadamente as capacidades permitidas e negadas. O resultado pretendido são permissões de encaminhamento explícitas, não um início de sessão interativo deixado disponível por acidente nem um proxy desativado pela sua própria restrição.