SSH — seguro e sem senha

Como desativar a autenticação por password, permitindo somente o acesso SSH através de autenticação por chaves?

Ao mesmo tempo que o SSH é uma importante e conveniente solução de acesso remoto, ele também pode trazer um grande risco, já que é muito simples para hacker efetuar um ataque de dicionário para conseguir acesso ao seu servidor, tentando várias combinações de login/senha em um curto espaço de tempo.

Se você acha que eu estou exagerando, experimente procurar por tentativas de acesso SSH em seus arquivo de log.

Existem diversas formas de reforçar a segurança de um servidor SSH, mas neste artigo vou me restringir as seguintes:

• Desativar o login de root.
• Configurar autenticação via chaves.
• Desativar o login por senha.
• Restringir o acesso SSH para usuários específicos.

Desativando o login de root

De longe este é o maior risco ao qual você pode se submeter quando estiver utilizando SSH. Isso por que, para um hacker, o root é o usuário que sempre existe no sistema, e por isso é o primeiro alvo de um ataque de dicionário.

Desativar o acesso de root ao SSH é simples, basta mudar a opção PermitRootLogin no arquivo /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
PermitRootLogin no

Salve o arquivo e reinicie o daemon do SSH:

systemctl sshd restart

A partir de agora você não conseguirá mais se autenticar via SSH diretamente com o usuário root. Será necessário acessar com um usuário comum primeiro, para depois se tornar root via sudo ou via su.

Configurando autenticação via chaves

Não é meu objetivo abordar como a criptografia assimétrica funciona. Vou me ater a criar um par de chaves, copiar a chave pública para o servidor ao qual precisamos nos conectar frequentemente e cadastrar nossa passphrase no ssh-agent.

Criando o par de chaves pública/privada

O processo é bem simples e seguro, basta executar o comando ssh-keygen sem parâmetros, confirmar que a chave será salva em /home/rodrigo/.ssh/id_rsa e informar a passphrase quando for pedida, repetindo-a em seguida para que não haja erros de digitação.

ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rodrigo/.ssh/id_rsa):
Created directory '/home/rodrigo/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
a4:a9:49:94:6b:61:96:f0:eb:ff:c3:17:90:bd:d9:01 rodrigo@rodrigojimmy2.mylabserver.com
The key's randomart image is:
+--[ RSA 2048]----+
|  .              |
|   o O   E       |
|    O   .o .     |
|   + + +o . .    |
|    = o S. + .   |
|   + o    x .    |
|    +  .   .     |
|     .  o .      |
|      ...o       |
+-----------------+

As chaves privada e pública foram salvas respectivamente em /home/rodrigo/.ssh/id_rsa e /home/rodrigo/.ssh/id_rsa.pub.

Cadastrando a passphrase no ssh-agent

Por fim, para que não seja necessário informar a passphrase sempre que formos efetuar o login usando este par de chaves, vamos cadastrá-la no ssh-agent:

# Inicia o agente ssh para o shell corrente
ssh-agent /bin/bash
# Adiciona a passphrase para a chave privada do usuário corrente
ssh-add

Esta operação deverá ser repetida para toda nova sessão do usuário. Mas se você estiver utilizando Linux com interface gráfica ou Mac, após efetuar este passo uma vez, nas próximas vezes que você se autenticar para acessar a interface gráfica, a passphrase estará acessível.

Copiando a chave pública para o servidor

Outro procedimento bem simples, mas que algumas vezes gera uma certa confusão.

Nós podemos copiar a chave pública do usuário rodrigo para o servidor www.umbrella.corp, por exemplo, para automatizar o login neste servidor para um usuário com este mesmo nome ou para qualquer outro usuário. Só temos que saber previamente a senha e o login por senha ainda deve estar ativo:

# A seguir a chave pública do usuário local rodrigo 
# está sendo copiada para o authorized_keys 
# do usuário joao no servidor www.umbrella.corp
# /home/joao/.ssh/authorized_keys
ssh-copy-id joao@www.umbrella.corp
The authenticity of host '52.91.143.99 (52.91.143.99)' can't be established.
ECDSA key fingerprint is da:3a:dc:6e:cc:9f:26:54:e7:58:ad:4f:33:c3:60:3b.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
joao@www.umbrella.corp's password:
Number of key(s) added: 1
Now try logging into the machine, with:
"ssh 'joao@www.umbrella.corp'"
and check to make sure that only the key(s) you wanted were added.

Depois de ter se autenticado digitando a senha do usuário joao, podemos testar o acesso para saber se a próxima autenticação se dará sem o uso de senha e sim através do par de chaves:

ssh joao@www.umbrella.corp

Tenha em mente que o acesso ssh realizado acima deve ser feito a partir do usuário rodrigo na máquina local. Este acesso deve ocorrer sem que a senha seja requisitada.

Tendo sucesso no passo anterior, podemos desativar o login por senha.

Desativando o login por senha

Outro procedimento simples, basta alterar a opção PasswordAuthentication para no, no arquivo de configuração do servidor SSH:

# /etc/ssh/sshd_config
PasswordAuthentication no

Salve o arquivo e reinicie o daemon do SSH:

systemctl sshd restart

Restringindo o acesso SSH para usuários específicos

Mais um procedimento simples e poderoso para reforçar a segurança.
Basta alterar a opção AllowUsers, no servidor SSH, informando os usuários que poderão se autenticar separados por espaço:

# /etc/ssh/sshd_config
AllowUsers joao 

Não se esqueça de reiniciar o SSH:

systemctl sshd restart

A partir de agora, somente o usuário joao conseguirá se conectar ao servidor por SSH.

Gostou? Então recomende!
Obrigado!