SSH apenas tunelando

Este artigo refere-se à implementação uma camada extra de segurança aos serviços que precisam estar disponíveis via internet (rede pública), mas por questões naturais (ausência de autenticação/criptografia, falta de confiança no produto, etc...) ou pura paranóia do administrador em não querer expor os serviços "no cru", ou abrir mais de uma porta no firewall, acabam não sendo disponibilizados.

Utilizaremos os mecanismos de autenticação, criptografia, "tunelamento" e multiplexação do OpenSSH, sem ter que amargar os efeitos colaterais em ceder acesso ao shell à um ou mais usuários. Então você questiona: Podemos utilizar qualquer VPN para isso, correto? Certamente, porém, o uso de VPNs (principalmente no caso do OpenVPN) cria uma determinada exclusão, nem todos os sistema operacionais o suportam (vide os Windows não-NT), além da relativa complexidade em implementar (existem outras VPNs, mas prefiro o citado acima).Todo procedimento será efetuado utilizando a conta administrativa presente nos sistemas Unix-like, o super-usuário 'root'.

Tudo se baseia na autenticação por chave-publica (impossível com autenticação mediante senha), é nela que iremos impor as restrições desejadas. Chega de lenga-lenga, já não aguento mais florear este texto :) Ponha a mão na massa!

Comece desabilitando a autenticação por senha. As linhas 'ChallengeResponseAuthentication' e 'PasswordAuthentication' no arquivo '/etc/ssh/sshd_config' devem ser configuradas com o valor 'no', além de não incluirem o caractere de comentário no início das mesmas ('#').

Reinicie o servidor SSH:

# /etc/init.d/ssh restart
Gere o par de chaves utilizando o 'ssh-keygen'. Aqui vai uma breve explanação sobre os parâmetros utilizados:

'-t rsa': Gera chaves do tipo RSA.

'-b 1024': Número de bits das chaves (quanto maior, mais segura é a autenticação, porém o consumo de banda e CPU aumenta durante o processo).

'-f chave_usuario': Nome dos arquivos a serem gerados (extensão '.pub' para a chave pública).

Incluindo as opções pertinentes, o comando fica:

# ssh-keygen -t rsa -b 1024 -f chave_usuario
Ao término do processo, será solicitada uma senha para a proteção da chave privada (extremamente útil em caso de perda ou roubo), recomendo não deixar em branco.Copie a chave pública ('chave_usuario.pub') para o arquivo 'authorized_keys':

# cat chave_usuario.pub > authorized_keys
A "mágica" começa aqui!

Existem várias strings que serão inseridas no arquivo 'authorized_keys' (o qual é lido pelo daemon do OpenSSH durante o processo de autenticação).

Explanação:

from="127.0.0.1,200.*,201.*" : Permite que a chave seja utilizada somente se o cliente conectar-se de um desses endereços. '127.0.0.1' (loopback, utilizaremos para testes), '200.*' e '201.*' endereços utilizados aqui no Brasil. Caso contrário, não será possível usufruir do serviço.

command="sleep 15m" : Executa o comando 'sleep' com o parâmetro '15m', ele é o responsável por "segurar" a sessão aberta durante 15 minutos (quando não houver conexões ao túnel). O comando sempre será executado, mesmo que o usuário especifique (ou não) um comando por conta própria.

no-X11-forwarding : Impede o "tunelamento" para com o X11.

no-agent-forwarding : Impede o uso do agente de autenticação em cascatas.

no-pty : Um dos mais importantes, impede o usuário de alocar um pty, não há interação alguma nesse caso.

permitopen="máquina:porta" : Impede que o usuário crie túneis para máquinas/portas não desejadas pelo administrador, somente o que é especificado será permitido. Este parâmetro pode ser repetido várias vezes (mesma máquina com portas diferentes ou várias máquinas/portas).

Utilize um editor de textos de sua preferência para fazer as alterações necessárias no arquivo (strings separadas por vírgula), tenha cuidado para não deformá-lo:

from="127.0.0.1,200.*,201.*",command="sleep 15m",no-X11-forwarding, no-agent-forwarding,no-pty,permitopen="recepcao:5900"
ssh-rsa AAAAB3......NzaC1yc2EAAAABIwAAAIEAxS8vY...

Nota: Todo o texto deve estar apenas em uma única linha, infelizmente não é viável reproduzí-lo aqui, devido ao seu comprimento.

Estamos quase lá, faltam apenas alguns passos!

Crie (caso não exsita) um diretório chamado '.ssh' no home do usuário, com a permissão '500', tendo o mesmo como dono:

# mkdir ~usuario/.ssh
# chmod 500 ~usuario/.ssh
# chown usuario:grupo ~usuario/.ssh

Crie um script chamado 'rc' no diretório '.ssh', este script servirá apenas para exibir um pequeno texto, informando ao mesmo que a sessão foi estabelecida com sucesso (afinal, todo usuário gosta de um retorno).

Conteúdo:

#!/bin/sh
echo 'Sessão estabelecida com sucesso, execute o cliente VNC.'

Torne-o executável:

# chmod 555 rc

Copie o arquivo 'authorized_keys' para o diretório '.ssh', a permissão para o arquivo é '444'.

# cp authorized_keys ~usuario/.ssh
# chmod 444 ~usuario/.ssh/authorized_keys

Trave os arquivos 'rc' e 'authorized_keys' com o comando 'chattr', nem mesmo o todo poderoso 'root' poderá alterá-los (ou deletá-los) sem remover primeiro o atributo:

# chattr +i ~usuario/.ssh/rc
# chattr +i ~usuario/.ssh/authorized_keys

Nota: É de praxe do OpenSSH utilizar também o arquivo 'authorized_keys2' como fonte de chaves para comparação, é muito importante que você crie um arquivo vazio com esse nome e trave-o com o 'chattr':

# touch ~usuario/.ssh/authorized_keys2
# chmod 444 ~usuario/.ssh/authorized_keys2
# chattr +i ~usuario/.ssh/authorized_keys2

Conecte-se ao servidor SSH e estabeleça o túnel, o alvo é uma máquina chamada 'recepcao' (o nome DNS tem que ser resolvível pelo servidor, endereços numéricos também são válidos, desde que especificados no 'authorized_keys'), porta 5900 (padrão do VNC):

# ssh -i chave_usuario -L5999:recepcao:5900 usuario@servidor

Faça um teste, veja se consegue digitar algo ou ter alguma interação no console.

Em outro terminal:

# xtightvncviewer localhost:5999

Gotcha!

Seu OpenSSH/usuário "tunnel-only" está pronto, não tem o menor perigo do usuário alterar os arquivos 'authorized_keys', 'authorized_keys2' e 'rc' (provavelmente com intenções maliciosas), mesmo que ele tenha acesso ao home localmente ou pela rede.

Nota: O commando 'chattr' só tem efeito em sistema de arquivos ext2/ext3.

Para mais dicas sobre o uso do SSH, leia: http://www.hardware.com.br/guias/acesso-remoto/