Como restringir um usuário SSH para permitir apenas o tunelamento SSH?

Como posso restringir um usuário no servidor SSH para conceder-lhe apenas os privilégios para SSH TUNNELING ? ou seja, eles não podem executar comandos, mesmo que se conectem via SSH.

Meus servidores Linux são Ubuntu 11.04 e OpenWrt.

linux ssh account-restrictions

— LanceBaynes
fonte

Respostas:

No lado do servidor, você pode restringir isso configurando o shell do usuário para /bin/true. Isso permitirá que eles se autentiquem, mas na verdade não executam nada, pois não recebem um shell para executá-lo. Isso significa que eles serão limitados a qualquer subconjunto de coisas que o SSH possa oferecer a eles. Se oferecer encaminhamento de porta, eles ainda poderão fazer isso.

No lado do cliente, você provavelmente desejará se conectar ao -N. Isso impede que o cliente solicite um comando remoto, como um shell, apenas para após a conclusão da parte de autenticação. _{Obrigado aos comentaristas por esclarecer isso.}

— Caleb
fonte

Vou tentar este: P thx!

— precisa saber é o seguinte

Para adicionar à resposta de Caleb, você também pode precisar dizer ao cliente para não executar um shell. Com a linha de comando openssh, isso é feito com o sinalizador -N. Existe uma opção semelhante no PuTTY, mas não me lembro do nome exato.

— Bill B

hmm, isso é basicamente segurança do lado do cliente, não? Estou procurando uma configuração de segurança no servidor, mas obrigado!

— precisa saber é o seguinte

Desculpe, eu não estava claro - quis dizer em combinação com a configuração do servidor. Tem sido minha experiência no passado que, se você definir o shell para algo que não é um shell, você não poderá se conectar porque ele tenta abrir um shell, mas não pode. Portanto, a segurança é imposta no lado do servidor (usando o método de Caleb), mas se você tiver problemas para se conectar depois disso, pode ser necessário definir o switch do lado do cliente.

— Bill B

Você cria esse usuário com useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— Fracz 11/06/16

A seguir, temos a vantagem de que os encaminhamentos de soquete do agente X11 e SSH também não são permitidos, o que ainda pode ser permitido no modo Calebs. Outra vantagem é que, se o usuário puder alterar seu shell padrão de qualquer outra maneira, isso ainda restringirá seu acesso SSH apenas aos encaminhamentos TCP.

Coloque o seguinte em seu /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

para permitir que o usuário that-restricted-guyencaminhe todas as conexões TCP através de sua máquina habilitada para SSH (conexão com esta máquina, também localhoste até mesmo conexão desta máquina com outras máquinas).

Se você quiser ainda mais restritivo (o que é uma boa ideia), você também pode fazer o seguinte:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Isso permitirá que o usuário even-more-restricted-guyencaminhe apenas conexões para a porta 12345.0.0.1 TCP 12345 (como é visível na sua máquina habilitada para SSH).

Quando o usuário normalmente se conecta, ele será desconectado instantaneamente porque o /bin/falsecomando será acionado, o que não fará nada além de sair instantaneamente com o código 1. Se você quiser evitar isso e manter a conexão de encaminhamento aberta, adicione o -Nsinalizador ao sshcomando Isso não tentará executar nenhum comando, mas ainda permitirá configurar os encaminhamentos de TCP.

Um exemplo de comando de encaminhamento que deve funcionar na última configuração:

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine

— aef
fonte

Eu reformulei a resposta como uma solução aprimorada sobre a resposta de Calebs.

— aef 14/01

Certo. Eu limpei também. É bom ver o mal-entendido resolvido. Boa noite.

— Jakuje 14/01

Você pode controlar o que as pessoas podem fazer no ssh combinando grupos, assumindo que sua versão do ssh é nova o suficiente para suportá-lo (openssh 5.x +).

Basicamente, nós os tratamos como se fossem usuários de sftp, mas permitimos o encaminhamento de tcp e, opcionalmente, especificamos os destinos para os quais eles podem encaminhar. Se você atribuir a eles um diretório pessoal, mas não criar diretórios nele, eles não poderão transferir nenhum arquivo porque não terão permissão para fazê-lo.

Match Group                     nicepeople
    PubkeyAuthentication        yes
    PasswordAuthentication      yes
    PermitEmptyPasswords        no
    GatewayPorts                no
    ChrootDirectory             /opt/dummy_location/%u
    ForceCommand                internal-sftp
    AllowTcpForwarding          yes
        PermitOpen              192.168.0.8:22
        PermitOpen              192.168.0.5:8080
    # Or leave out the PermitOpen to allow forwarding to anywhere.
    HostbasedAuthentication     no
    RhostsRSAAuthentication     no
    AllowAgentForwarding        no
    Banner                      none

Você pode repetir esses blocos do Grupo de correspondências para cada grupo que deseja fornecer comportamentos ou restrições diferentes.

Você pode controlar ainda mais onde essa pessoa pode ir na rede usando iptables

/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT

Isso pressupõe que o GID do grupo "pessoas legais" seja 500.

Algumas das opções ssh acima estão disponíveis nas versões mais antigas do openssh, mas não na seção Match Group. O Match Group é muito limitado no OpenSSH 4.xe versões anteriores.

— Aaron
fonte