Configuração do cliente SSH

Ao ser ativado, 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:

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

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

Caso você omita o nome do usuário, o SSH presume que você quer acessar usando o mesmo login que está utilizando 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:

A configuração do arquivo “/etc/hosts” vale apenas para a sua própria máquina, ele nada mais é do que um arquivo com aliases. Se você quiser que os apelidos sejam válidos também para as demais máquinas da rede, a melhor opção é configurar um servidor DNS de rede local.

Voltando à configuração do SSH, vamos a algumas opções importantes dentro da configuração do cliente SSH, que vão no arquivo “/etc/ssh/ssh_config“:

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

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 usando um terminal local.

O maior problema com o uso de aplicativos gráficos via SSH é que ele só funciona satisfatoriamente dentro da rede local. Via Internet os aplicativos gráficos ficam realmente muito lentos (mesmo em uma conexão de 4 ou 8 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 NX Server (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.

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:

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

Keep Alive: Outro problema comum relacionado ao SSH é 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” ou um “pwd” 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 o recurso, adicione a opção “ServerAliveInterval” no arquivo, especificando o intervalo entre o envio dos pacotes (em segundos):

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

Como em outros arquivos de configuração, você não precisa se preocupar em incluir cada uma das opções disponíveis, pois o SSH simplesmente usa os valores default para as opções não incluídas no arquivo. Com isso, você precisa se preocupar apenas com as opções que conhece, omitindo as demais.

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 possui uma chave pública, que é enviada 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 (do servidor), 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 acesso) 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 de usá-la para acessar o servidor verdadeiro sem que você desconfie. Entretanto, isso é previsto dentro do design do SSH; ele percebe que a identificação do servidor mudou e lhe avisa do problema:

Para continuar é preciso que você remova a linha com a identificação do servidor salva no arquivo .ssh/know_hosts, dentro do diretório home do usuário que está utilizando. Isso pode ser feito de duas formas.

A primeira é remover a chave usando o comando “ssh-keygen -R”, seguido pelo endereço IP ou o domínio do servidor (o mesmo que você especifica ao se conectar a ele), como em:

Como pode ver, o comando substituiu a edição manual do arquivo, removendo a linha correspondente ao servidor e salvando um backup do arquivo original por precaução.

A segunda opção é editar diretamente o arquivo “.ssh/known_hosts“, comentando ou removendo a linha referente ao servidor (deixando as demais). Dentro do arquivo, você verá uma longa linha para cada servidor acessado, começando com o endereço IP ou o nome de domínio usado no acesso.

Em qualquer um dos dois casos, da próxima vez que tentar se conectar, o SSH exibe uma mensagem mais simpática, perguntando se você quer adicionar a nova chave:

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 manualmente.

As chaves de identificação 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 sistema no servidor, ou quando substituí-lo por outra máquina, 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 última opção seria desabilitar a checagem das chaves, adicionando a opção “StrictHostKeyChecking no” na configuração dos clientes. Contudo, isso não é recomendável, pois desabilita completamente a checagem, abrindo brechas para ataques.