Servidor SSH – Resumo dos seus arquivos de configuração

Comandos intermediários do GNU/Linux

Servidor SSH – Resumo dos seus arquivos de configuração

A configuração do servidor, independentemente da distribuição usada, vai no arquivo “/etc/ssh/sshd_config“, enquanto a configuração do cliente vai no “/etc/ssh/ssh_config“. Note que muda apenas um “d” entre os dois.

Outra observação é que além do OpenSSH, que abordo aqui, existem outras versões do SSH, como o Tectia (uma versão comercial, disponível no http://ssh.com) e o SunSSH que, embora conservem diferenças no funcionamento e na configuração, são compatíveis entre si. O SSH é, na verdade, um protocolo aberto e não o nome de uma solução específica.

O uso básico do SSH é bastante simples, já que basta usar o comando “ssh login@servidor” para acessar o servidor remoto e, a partir daí, rodar os comandos desejados. Entretanto, essa é apenas a ponta do iceberg. O SSH é tão rico em funções que até mesmo os administradores mais experientes raramente usam mais do que um punhado das funções disponíveis.

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 “10.0.0.2”, usando o login “ecouto”, por exemplo, o comando seria:

$ ssh ecouto@10.0.0.2

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

$ ssh -l ecouto 10.0.0.2

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

$ ssh ecouto@gnulinux.wordpress.com

Caso eu 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 eu estiver logado como “joao”, ele tentará fazer login usando uma conta “joao” no servidor remoto. Naturalmente, só funciona caso você use o mesmo login em ambas as máquinas.

Ao acessar micros dentro da rede local, poderei também chamá-los pelo nome, como em “ssh ecouto@servidor“. Neste caso, irei 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
10.0.0.3 arq-server
10.0.0.2 servidor

A configuração do arquivo “/etc/hosts” vale apenas para a própria máquina, ele nada mais é do que um arquivo com aliases. Se eu 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, irei 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:

ForwardX11 yes

Outra opção é adicionar o parâmetro “-X” ao se conectar, como em “ssh -X mario@10.0.0.2“. A partir daí, poderei 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. 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:

Compression = yes

Também posso 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 eu posso querer 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.

ambém posso 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, adicionei a opção “ServerAliveInterval” no arquivo, especificando o intervalo entre o envio dos pacotes (em segundos):

ServerAliveInterval 120

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

ForwardX11 yes
Compression = yes

Port 22
ServerAliveInterval 120

Como em outros arquivos de configuração, eu não preciso 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, irei precisa me preocupar apenas com as opções que já conheço, 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 eu me conecto 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 eu tento acessar meu servidor baseado no domínio.

O servidor falso pode ser configurado para gravar as 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 à minha senha, mas tempo de usá-la para acessar o servidor verdadeiro sem que eu desconfie. Entretanto, isso é previsto dentro do design do SSH; ele percebe que a identificação do servidor mudou e me avisa do problema:

Para continuar é preciso que eu 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 eu especifico ao se conectar a ele), como em:

# ssh-keygen -R 10.0.0.5

/home/gdhn/.ssh/known_hosts updated.
Original contents retained as /home/gdhn/.ssh/known_hosts.old

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, eu irei ver que 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 eu tentar se conectar, o SSH exibe uma mensagem mais simpática, perguntando se eu quero 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 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. Eu também poderei 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.

Eu também posso configurar várias opções relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo “/etc/ssh/sshd_config”. Assim como no caso da configuração do cliente, a maior parte das opções dentro do arquivo podem ser omitidas (pois o servidor simplesmente utiliza valores default para as opções que não constarem no arquivo), mas, de qualquer forma, é saudável especificar todas as opções que conhece: além de evitar enganos, é uma forma de praticar e memorizar as opções.
Porta: Uma das primeiras linhas é a:

Port 22

Esta é a porta que será usada pelo servidor SSH. O padrão é usar a porta 22. Ao mudar a porta do servidor aqui, eu terei que usar a opção “-p” ao conectar a partir dos clientes para indicar a porta usada, como em:

# ssh -p 2222 ecouto@gnulinuxbr.wordpress.com.br

Outra opção é editar o arquivo “/etc/ssh/ssh_config” (nos clientes) e alterar a porta padrão usada por eles. Mudar a porta padrão do SSH é uma boa idéia quando entra a questão com a segurança. Muitos dos ataques “casuais” (quando o atacante simplesmente varre faixas inteiras de endereços, sem um alvo definido), começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, procurando por servidores com portas conhecidas abertas, como a 21, a 22 e a 80. Isso torna o teste mais rápido, permitindo localizar rapidamente um grande volume de hosts com portas abertas. A partir daí, os ataques vão sendo refinados e direcionados apenas para os servidores vulneráveis encontrados na primeira varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvável como a porta 32456 ou a 54232 reduz sua exposição.

Controle de acesso: Logo abaixo vem a opção “ListenAddress“, que permite limitar o SSH a uma única interface de rede (mesmo sem usar firewall), útil em casos de micros com duas ou mais placas; o típico caso em que eu quero que o SSH fique acessível apenas na rede local, mas não na Internet, por exemplo. Digamos que o servidor use o endereço “10.0.0.2” na rede local e eu queira que o servidor SSH não fique disponível na Internet. Então eu adicionaria a linha:

ListenAddress 10.0.0.2

Note que especificamos nesta opção o próprio IP do servidor na interface escolhida, não a faixa de IP’s da rede local ou os endereços que terão acesso a ele.

Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira versão do protocolo. Por padrão, o servidor SSH aceita conexões de clientes que utilizam qualquer um dos dois protocolos, o que é indicado na linha:

Protocol 2,1

O protocolo SSH 1 tem alguns problemas fundamentais de segurança, por isso é recomendável desativar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas:

Protocol 2

Restringir a versão do protocolo ajuda a melhorar a segurança, pois evita que usuários utilizando clientes SSH antigos abram brechas para ataques. Existem, por exemplo, muitos clientes SSH para uso em celulares que suportam apenas o SSH 1 e utilizam algoritmos fracos de encriptação. Desativando a compatibilidade com o SSH 1 eu cortarei o mal pela raiz.

Usuários e senhas: Outra opção interessante, geralmente colocada logo abaixo, é a:

PermitRootLogin yes

Esta opção determina se o servidor aceitará que usuários se loguem como root. Do ponto de vista da segurança, é melhor deixar esta opção como “no”, pois assim o usuário precisará primeiro se logar usando um login normal e rodar comandos como root usando o “sudo” ou “su -“:

PermitRootLogin no

Dessa forma, é preciso saber duas senhas, ao invés de saber apenas a senha do root, eliminando a possibilidade de algum atacante obstinado conseguir adivinhar a senha de root e, assim, obter acesso ao servidor.

Por padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas eu também psso refinar isso através da opção “AllowUsers”, que especifica uma lista de usuários que podem usar o SSH. Quem não estiver na lista, continua usando o sistema localmente, mas não consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usuários que não têm necessidade de acessar o servidor remotamente coloquem a segurança do sistema em risco. Para permitir que apenas os usuários “joao” e “maria” possam usar o SSH, por exemplo, adicionei a linha:

AllowUsers joao maria

Também posso ainda inverter a lógica, usando a opção “DenyUsers”. Neste caso, todos os usuários cadastrados no sistema podem fazer login, com exceção dos especificados na linha, como em:

DenyUsers ricardo manuel

Outra opção relacionada à segurança é a:

PermitEmptyPasswords no

Esta opção faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que alguém consiga se conectar ao servidor “por acaso” ao descobrir a conta desprotegida. Lembre-se de que a senha é justamente o ponto fraco do SSH. De nada adianta usar 2048 bits de encriptação se o usuário escreve a senha em um post-it colado no monitor, ou deixa a senha em branco.

Banner: Alguns servidores exibem mensagens de advertência antes do prompt de login, avisando que todas as tentativas de acesso estão sendo monitoradas ou coisas do gênero. A mensagem é especificada através da opção “Banner”, onde eu indico um arquivo de texto com o conteúdo a ser mostrado, como em:

Banner = /etc/ssh/banner.txt

X11 Forwarding: Além de ser usada na configuração dos clientes, a opção “X11Forwarding” pode ser também incluída na configuração do servidor:

X11Forwarding yes

Ela determina se o servidor permitirá que os clientes executem aplicativos gráficos remotamente. Se o servidor for acessado via Internet ou se possui um link lento, eu posso deixar esta opção como “no” para economizar banda. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto. Note que ao usar “X11Forwarding no” o encaminhamento é recusado pelo próprio servidor, de forma que o usuário não consegue rodar aplicativos gráficos mesmo que a opção esteja ativa na configuração do cliente.

– SFTP: O SSH inclui um módulo de transferência de arquivos (o SFTP). Ele é ativado através da linha:

Subsystem sftp /usr/lib/sftp-server

É realmente necessário que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se você realmente deseja desativá-lo.