Como restringir a autoridade do túnel ssh a uma determinada porta?

Question

Eu tenho um programa em execução na porta do servidor remoto 9999. Como ele não suporta nenhum tipo de criptografia e autenticação, estou usando o túnel ssh para acessá-lo.

Este é o comando que estou usando:

ssh -L 9999:localhost:9999 user@remotehost

Para manter este túnel vivo. Eu escrevo um script ssh para monitorar e reiniciá-lo se algo der errado. Então, eu tenho que armazenar a senha no script.

Mas, considerando a possibilidade deste cliente-servidor ser hackeado. Eu acho que é melhor se eu puder restringir este túnel a uma autoridade mínima.

Então, é possível restringir o usuário do remotehost só pode usar encaminhamento de túnel ssh para a porta 9999?

    

Answer 1

In order to keep this tunnel alive. I write a ssh script to monitor and restart it if anything went wrong.

Você deve procurar usar o autossh .

So, I have to store the password in the script.

Você deve usar a autenticação de chave pública em vez de uma senha.

So, is it possible to restrict the remotehost user can only used ssh tunnel forwarding to port 9999?

Primeiro, verifique se o usuário não consegue abrir um shell interativo na máquina servidor . Basta criar uma conta específica que é usada apenas para abrir este túnel, se você não estiver usando um. Defina o shell padrão desta conta para /sbin/nologin (ou /bin/false se o primeiro não existir)

useradd tunnel
usermod -s /sbin/nologin tunnel

Você deve ir na máquina cliente e gerar um par de chaves ssh e copiar a chave pública para o servidor.

ssh-keygen
ssh-copy-id tunnel@server

Finalmente, no servidor , restrinja a capacidade de encapsular qualquer coisa, mas localhost: 9999 usando o arquivo authorized_keys. Anexar Prefira o seguinte à chave autorizada que foi carregada com ssh-copy-id .

no-pty,permitopen="localhost:9999"

O no-pty é outra configuração de segurança que não permite abrir um shell interativo. A linha resultante é algo como isto:

no-pty,permitopen="localhost:9999" ssh-rsa AAAAB3NzaC1y...Rdo/R user@clientbox

Pode haver outras opções úteis que você pode definir no authorized_keys file . Para mais informações, leia man sshd .

Além disso, você também pode bloquear a conta no bloco /etc/ssh/sshd_config via Match da conta:

Match User tunnel
   ForceCommand /sbin/nologin # An additional configuration to disable any shell command, superfluous when the user's shell is already set to '/sbin/nologin'
   AllowAgentForwarding no
   AllowTcpForwarding local # Disallow port forwarding of remote ports, superfluous when using the 'permitopen' restriction in authorized_keys
   AllowStreamLocalForwarding no # Probably not necessary, as the user needs to have access rights to access the AF_UNIX port
   X11Forwarding no # Because some default configuration files, e.g. from Debian, set it to yes
# Beware: Match does not end with indentation!

Estas são apenas dicas para melhorar a configuração atual do seu túnel ssh. Como Dennis sugeriu, existem outras soluções de tunelamento mais elegantes que você deve considerar.

    

Answer 2

Não, isso não é possível. Você pode desativar o encaminhamento de portas, mas isso desabilita o encaminhamento de qualquer porta, não há configuração por porta.

Sim, isso é possível ao prefixar permitopen="localhost:9999" à chave em ~/.ssh/authorized_keys no servidor, consulte a página do manual sshd (obrigado Kenny!). Você também vai querer forçar um comando que não faz nada além de dormir, para ter certeza de que qualquer atacante não pode pegar um shell (e assim remover essa restrição, e fazer outras coisas ruins).

Dito isto, o ssh é a maneira errada de fazer isso. Por que não usar o stunnel para disponibilizar o serviço em SSL? Ou configure uma conexão VPN entre as duas máquinas com openvpn ?

    

Answer 3

Eu daria uma olhada na ferramenta autossh .

• link
• link

A página do manual está disponível aqui:

• link

Eu o uso para manter as portas abertas para um servidor IMAP e SMTP que estão atrás de um firewall. Por exemplo:

% autossh -M 0 -f -N -L 2025:localhost:25 -L 2143:localhost:143 \
          myuser@remoteserver

Parece estar na maioria dos grandes repositórios Linux distros também.