Posso desativar o acesso ao shell interativo enquanto encapsulamos o tráfego da Web através do SSH?

Estou pensando em implementar o encapsulamento SSH como uma solução VPN barata para que usuários externos acessem aplicativos da Web voltados apenas para a Intranet.

Atualmente, estou usando o Ubuntu Server 10.04.1 64 bits com o OpenSSH instalado.

Estou usando o Putty nas caixas do Windows para criar um túnel em uma porta local para o meu servidor ssh.

start putty -D 9999 mysshserver.com -N

Em seguida, uso o comando tell Firefox para usar um proxy SOCKS no localhost: 9999.

O sinalizador -N desativará o shell interativo do lado do cliente. Existe uma maneira de fazer isso no lado do servidor?

Além de desativar o acesso root, usar a autenticação de chave rsa e alterar a porta padrão; existem outras práticas de segurança óbvias que devo seguir para esse fim? Meu objetivo é simplesmente conseguir encapsular o tráfego da web.

Após quatro anos, essa resposta mereceu uma atualização. Enquanto originalmente eu authorized_keysme usava e provavelmente ainda o usaria em alguns casos selecionados, você também pode usar o sshd_configarquivo de configuração do servidor central .

sshd_config

Você pode designar (para o seu caso de uso particular) um grupo, como proxy-onlyou Matchusuários individuais. In sshd_config. Isso é feito após as configurações globais e revoga, repete ou refina algumas das configurações fornecidas nas configurações globais.

Nota: algumas das sintaxes / diretivas usadas em sshd_config(5)estão documentadas na manpágina para ssh_config(5). Em particular, certifique-se de ler a seção PADRÕES de ssh_config(5).

Para um grupo, isso significa que seu Matchbloco começaria assim:

Match group proxy-only

Você pode Matchos seguintes critérios: User, Group, Host, LocalAddress, LocalPorte Address. Para corresponder a vários critérios, basta separar por vírgula os pares padrão-critério ( group proxy-onlyacima).

Dentro desse bloco, que é tradicionalmente recuado de maneira apropriada, por questões de brevidade (mas não é necessário), você pode declarar as configurações que deseja aplicar ao grupo de usuários sem precisar editar todos os authorized_keysarquivos dos membros desse grupo.

A no-ptyconfiguração de authorized_keysseria espelhada por uma PermitTTY noconfiguração e command="/sbin/nologin"se tornaria ForceCommand /sbin/nologin.

Além disso, você também pode definir mais configurações para satisfazer a paranóia de um administrador, como chrootcolocar o usuário em sua pasta pessoal e acabar com algo assim:

Match group proxy-only
    PermitTTY no
    ForceCommand /sbin/nologin
    ChrootDirectory %h
    # Optionally enable these by un-commenting the needed line
    # AllowTcpForwarding no
    # GatewayPorts yes
    # KbdInteractiveAuthentication no
    # PasswordAuthentication no
    # PubkeyAuthentication yes
    # PermitRootLogin no

(verifique se você precisa ou deseja as linhas comentadas e descomente conforme necessário)

O %hé um token que é substituído pelo diretório inicial do usuário ( %uproduziria o nome do usuário e %%um sinal de porcentagem). Eu achei ChrootDirectoryparticularmente útil confinar meus sftp-onlyusuários:

Match group sftp-only
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication no

Lembre-se de que apenas determinadas diretivas podem ser usadas em um Matchbloco. Consulte a manpágina sshd_config(5)para detalhes (pesquise Match).

Keys_ autorizado

Nota: a parte abaixo desta observação foi minha resposta original. Enquanto isso - mas também depende dos recursos da sua sshdversão exata -, eu usaria o método descrito acima na maioria dos casos.

Sim, você pode, da maneira mais refinada possível, atribuir chaves públicas. Além de nologin, como recomendado por ajdecon, sugiro definir o seguinte na frente da entrada de chave em authorized_keys:

no-pty ssh-rsa ...

O no pty informa ao lado do servidor que nenhum pseudo-terminal deve ser alocado para essa chave.

Você também pode forçar a execução de algo como nologin para uma chave específica, acrescentando isto:

command="/sbin/nologin",no-pty ssh-rsa ...

Para qualquer usuário exclusivo de tunelamento, altere seu shell de login para / sbin / nologin. Dessa forma, seu usuário não poderá acessar um shell no servidor, mas ainda poderá executar túneis ssh configurados no cliente.

Sei que essa talvez não seja a resposta que você procura, mas você já pensou em usar o OpenVPN como alternativa?

Caso esteja pronto para desistir da autenticação de usuário / senha e usar chaves para efetuar login, você pode especificar os parâmetros s para cada chave pública.

Parâmetros notáveis ​​são:

command = "command"

Especifica que o comando é executado sempre que essa chave é usada para autenticação. O comando fornecido pelo usuário (se houver) é ignorado.

e

restringir

Ative todas as restrições, ou seja, desative a porta, o agente e o encaminhamento X11, além de desativar a alocação de PTY e a execução de ~ / .ssh / rc.

e finalmente

encaminhamento de porta Ative o encaminhamento de porta anteriormente desativado pela opção restringir.

Com eles, você pode restringir o usuário desse par de chaves em particular o que ele pode fazer com a sessão SSH.

Seria assim:

restrict,port-forwarding,command="/sbin/nologin" ssh-rsa <base64-encoded key>

Eu recomendo tentar Tunnelier . É muito mais fácil de configurar / gerenciar.