Configuração do cliente

Ao ser habilitado, o padrão do servidor SSH é permitir acesso usando qualquer uma das contas de usuário cadastradas no sistema, pedindo apenas a senha de acesso. Para acessar o servidor “192.168.0.2”, usando o login “morimoto”, por exemplo, o comando seria:

$ ssh morimoto@192.168.0.2

Ao invés de usar a arroba, você pode também especificar o login usando o parâmetro “-l” (de login), como em:

$ ssh -l morimoto 192.168.0.2

Você pode também acessar o servidor usando o nome ou domínio, como em:

$ ssh morimoto@web.kurumin.com.br

Caso você omita o nome do usuário, o SSH presume que você quer acessar usando o mesmo nome de usuário que está usando na máquina local. Se você está logado como “tux”, ele tentará fazer login usando uma conta “tux” no servidor remoto. Naturalmente, só funciona caso você use o mesmo login em ambas as máquinas.

Ao acessar micros dentro da rede local, você pode também chamá-los pelo nome, como em “ssh morimoto@servidor”. Neste caso, você precisará primeiro editar o arquivo /etc/hosts (no cliente), incluindo os números de IP das máquinas e os nomes correspondentes. O formato deste arquivo é bem simples, basta fornecer o IP e o nome da máquina correspondente, um por linha, como em:

127.0.0.1 localhost
192.168.0.2 servidor
192.168.0.6 athenas

– Verificação do servidor: Como parte das verificações de segurança, o SSH utiliza também um sistema baseado em chaves assimétricas para verificar a identidade do servidor. O servidor tem uma chave pública, que envia ao cliente na primeira conexão. As identificações de todos os servidores conhecidos ficam armazenadas no arquivo “.ssh/known_hosts” dentro do seu diretório home. Sempre que você se conecta daí em diante, o cliente SSH envia um “desafio” ao servidor, uma frase encriptada usando a chave pública, que só pode ser descoberta usando a chave privada.

Isso previne um tipo de ataque muito comum chamado “man in the middle” (que poderia ser traduzido para “intermediário”, ou “impostor”), em que alguém simplesmente substitui o servidor por outra máquina, usando o mesmo IP, ou sabota o servidor DNS da rede (ou do provedor) de forma que ele entregue um IP forjado quando você tenta acessar seu servidor baseado no domínio.

O servidor falso pode ser configurado para gravar sua senha e responder com uma mensagem do tipo “O servidor está em manutenção, tente novamente daqui a algumas horas”. Dessa forma, ele vai ter não apenas acesso à sua senha, mas tempo para usá-la para acessar o servidor verdadeiro sem que você desconfie. Por sorte, o SSH percebe que a identificação do servidor mudou e lhe avisa do problema:

Para continuar é preciso que você edite manualmente o arquivo “.ssh/known_hosts“, dentro do home e remova a linha com a antiga identificação do servidor, deixando as demais. Da próxima vez que tentar se conectar, o SSH exibe uma mensagem mais simpática, perguntando se você quer adicionar a nova chave:

The authenticity of host ‘192.168.1.200 (192.168.1.200)’ can’t be established.
RSA key fingerprint is f1:0f:ae:c6:01:d3:23:37:34:e9:29:20:f2:74:a4:2a.
Are you sure you want to continue connecting (yes/no)?

Não existe forma de fazer com que o cliente SSH adicione as novas chaves automaticamente, isso seria uma brecha de segurança. É sempre preciso primeiro remover a chave antiga no arquivo “~/known_hosts” manualmente.

As chaves são geradas durante a instalação do SSH e salvas nos arquivos “/etc/ssh/ssh_host_rsa_key” e “/etc/ssh/ssh_host_dsa_key” (no servidor). Para não disparar o alarme nos clientes quando precisar reinstalar o servidor, salve os dois arquivos em um pendrive e restaure-os depois da instalação. Você pode fazer isso mesmo ao migrar para outra distribuição, pois as localizações dos dois arquivos não mudam.

Uma opção, seria desabilitar a checagem das chaves, adicionando a linha “StrictHostKeyChecking no” na configuração dos clientes. Contudo, isso não é recomendável, pois desabilita completamente a checagem, abrindo brechas para ataques.

– Compressão: No caso de servidores acessíveis via internet, você pode reduzir um pouco o consumo de banda ativando a compressão de dados via gzip, o que é feito adicionado a linha:

Compression = yes

Você pode também ativar a compressão adicionando a opção “-p” na hora de se conectar. Quase todas as opções do cliente SSH podem ser especificadas tanto no arquivo, quanto via linha de comando.

– Aplicativos gráficos: Além de oferecer acesso via linha de comando, o SSH permite rodar aplicativos gráficos remotamente (X11 forwarding). Algumas distribuições, como o Slackware, trazem o recurso desabilitado por padrão. Nestes casos, edite o arquivo “/etc/ssh/ssh_config” (a configuração do cliente) e substitua a linha “ForwardX11 no” por:

ForwardX11 yes

Outra opção é adicionar o parâmetro “-X” ao se conectar, como em “ssh -X tux@192.168.0.1”. A partir daí, você pode chamar os aplicativos gráficos normalmente, como se estivesse num terminal local.

O maior problema com o uso de aplicativos remotos via SSH é que ele só funciona satisfatoriamente via rede local. Via internet os aplicativos gráficos ficam realmente muito lentos (mesmo em uma conexão de 1 ou 2 megabits), pois o protocolo do X é otimizado para uso local, com uso intensivo de pacotes de retorno e sem nenhum tipo de cache. Isso faz com que muitos administradores desabilitem o X11 forwarding no próprio servidor.

Para rodar aplicativos gráficos de forma segura via internet, a melhor solução é usar o FreeNX (que veremos em detalhes mais adiante). Ele é um sistema de acesso remoto baseado no SSH, que utiliza um protocolo bastante otimizado. Nele você tem um desktop completo (similar ao VNC), mas com um desempenho muito superior, mesmo em conexões via modem.

– Keep Alive: Concluindo a configuração do cliente, outro problema comum é a conexão ser fechada pelo servidor depois de alguns minutos de inatividade. Em muitas situações você quer manter a conexão aberta por longos períodos, sem precisar ficar dando um “ls” a cada dois minutos para manter a conexão aberta. Você pode evitar o problema fazendo com que o próprio cliente mande pacotes periodicamente a fim de manter a conexão aberta. Para ativar isso, adicione a linha abaixo no “/etc/ssh/ssh_config”:

ServerAliveInterval 120

Este é um exemplo de arquivo “/etc/ssh/ssh_config” configurado com as opções que vimos até aqui (excluindo os comentários):

ForwardX11 yes
Compression = yes
Port 22
ServerAliveInterval 120