Implementando segurança no SSH

Compartilho através deste artigo algumas dicas valiosas para aumentar o nível de segurança do acesso SSH ao seu servidor.

[ Hits: 20.750 ]

Por: Thiago Henrique de Lima em 19/06/2012


Introdução



Para quem administra servidores GNU/Linux ou até mesmo alguns outros Unix Like, o serviço de SSH é essencial.

Porém, é também um serviço que gera muitas preocupações aos administradores de sistemas, que frequentemente são vítimas de tentativas de invasão em seus servidores através deste serviço. Estas frequentes tentativas geram uma preocupação muito grande em qualquer administrador de sistemas que quer manter a segurança e integridade de seu ambiente: "Como manter meu SSH seguro?"

Neste artigo, que publiquei originalmente em meu blog, quero compartilhar algumas dicas de técnicas que eu descobri na Internet ou mesmo que a experiência do dia a dia me ensinaram, e que podem ajudar nesta árdua tarefa.

Utilize somente autenticação via troca de chaves

O SSH permite dois tipos de autenticação, um por senha, outro através de troca de chaves.

As chaves nada mais são do que dois arquivos de texto contendo uma chave RSA (ou DSA, caso você prefira), uma que ficará no servidor, e outra que deverá ficar com o usuário. No momento da autenticação, a chave privada (que fica com o usuário que irá acessar o servidor) é enviada ao servidor, e caso as chaves "casem", você terá acesso ao shell via SSH. O acesso via chaves é mais seguro, pois o usuário deverá obrigatoriamente ter o arquivo de chave privada, cujo conteúdo, diga-se de passagem, é humanamente impossível de ser decorado.

O serviço de SSH possibilita que você desabilite o uso de senhas e utilize somente a autenticação via chaves. Para isto, primeiramente, devemos gerar o par de chaves que serão utilizados neste processo:

ssh-keygen -t rsa -b 2048

Este comando irá te fazer algumas perguntas, geralmente, a primeira é o local onde você quer gerar o par de chaves, e a segunda é qual é a "passphrase" que você deseja atribuir em sua chave privada. Para salvar o par de chaves no local padrão, e para não atribuir nenhuma passphrase, basta simplesmente apertar ENTER no momento em que as perguntas forem feitas.

Se você fez desta forma, no HOME do seu usuário existirá um diretório chamado .ssh, no qual você encontrará os arquivos id_rsa.pub e id_rsa.

Caso tenha executado este procedimento no servidor, somente renomeie o arquivo id_rsa.pub para authorized_keys:

mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

Caso tenha realizado o procedimento direto em seu desktop (obviamente com Linux), basta copiar o arquivo id_rsa.pub direto para o servidor, e ajustar as permissões da chave privada no desktop, para que possa realizar o acesso:

scp id_rsa.pub usuario@servidor:~/.ssh/authorized_keys
$ chmod 644 id_rsa


Como o SSH por padrão já vem configurado para permitir acesso via troca de chaves, o comando abaixo deverá resultar em um acesso imediato ao servidor, sem solicitação de senha:

ssh -i ~/.ssh/id_rsa usuario@servidor

Se o seu SSH não teve nenhuma alteração de suas configurações padrão (bem provável), você agora está no console do servidor. :) E se você já está dentro do servidor, significa que já podemos desabilitar a autenticação via senha, mantendo somente a autenticação via troca de chaves:

# vim /etc/ssh/sshd_config

E altere:

# A diretiva PasswordAuthentication é responsável por permitir autenticação por senhas
# Alterá-la para "no" fará com que o servidor pare de aceitar senhas como forma de autenticação
PasswordAuthentication no

Pronto! Basta reiniciar o SSH e seu SSH só será acessível via troca de chaves, nada mais de senhas e suas infinitas tentativas de Brute Force.

Possíveis configurações que impeçam a troca de chaves

Por outro lado, se no momento da autenticação via chave pública você não tenha conseguido acesso, isto pode ter sido causado por diversos fatores, entre eles, o mais provável, é que seu SSH não esteja configurado adequadamente para utilizar chaves, ou o nome do arquivo de chaves publicas (authorized_keys) foi alterado nas configurações do servidor. Para termos certeza se seu problema é este, vamos conferir qual é o valor das diretivas PubkeyAuthentication e AuthorizedKeysFile:

# sshd -T | egrep -i '(AuthorizedKeysFile|PubkeyAuthentication)'
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys


Se o seu SSH não estiver configurado como é esperado por este artigo, o comando acima retornará resultados diferentes do esperado acima. Para ajustarmos, altere no arquivo /etc/ssh/sshd_config o valor destas diretivas:

# vim /etc/ssh/sshd_config

# Lembrando que os valores das diretivas abaixo são os valores padrão do SSH.
AuthorizedKeysFile yes
authorizedkeysfile .ssh/authorized_keys

Após isto, reinicie o serviço de SSH, e tente autenticar via troca de chaves novamente.

# /etc/init.d/sshd restart

Se você conseguiu, basta seguir o procedimento de desativação da senha para autenticação.

Caso não, nada que uma Googlada ou mesmo um pedido de ajuda aqui não possam ajudá-lo a resolver. ;)

    Próxima página

Páginas do artigo
   1. Introdução
   2. Restrinja o acesso à usuários específicos com as diretivas AllowGroups e AllowUsers
   3. Utilize sempre um firewall ou Port Knocking
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Análise de Atividades Suspeitas com Audit

Implementando a segurança em servicos de acesso remoto

Teste de vulnerabilidades com OpenVAS 3.0

Criando senhas seguras com o mkpasswd

Servidor de log no Debian com Syslog-ng

  
Comentários
[1] Comentário enviado por fabio em 19/06/2012 - 08:14h

Belas dicas! Conteúdo simples, mas extremamente útil.

[2] Comentário enviado por eldermarco em 19/06/2012 - 09:48h

Muito bom! Vou seguir essas dicas e implementar isso nos PCs da minha casa.

[3] Comentário enviado por silent-man em 19/06/2012 - 10:23h

Boas dicas

Apenas para acescentar:

Na diretiva AllowUsers é possível especificar de onde(de qual ip, estação, host, etc...) determinado usuário poderá fazer acesso ssh.

Ex:

AllowUsers gleison@minhaestacao.com.br gleison@10.1.1.10

Assim, o usuário gleison só poderá fazer conexões ssh oriundas dos hosts 10.1.1.10 ou minhaestacao.com.br.

Esta configuração foi muito importante em um abiente de Oracle Rac. Onde o usuário oracle NECESSITA acesso em ambos os nós utilizando troca de chaves. Então foi permitido acesso SSH do usuário oracle apenas entre os hosts Oracle Rac.

Sds;

[4] Comentário enviado por danniel-lara em 19/06/2012 - 12:59h

Muito bom o artigo , Parabéns

[5] Comentário enviado por JoseHenriqueRJ em 19/06/2012 - 17:15h

Muito bom.
Aqui na empresa nós utilizamos o Pegeant com chave+senha. Nada além disso!
Boa dica!

[6] Comentário enviado por cristianovicosa em 21/06/2012 - 22:19h

Muito bom!

[7] Comentário enviado por m4cgbr em 24/06/2012 - 03:25h

THenrique

Deu certo, conectei normalmente, porém quando execute o comando: su - por exemplo diz que eu não tenho permissão?

Porque isso ocorre? Sei que se adicionar meu usuário no /etc/sudoers resolvo, porém o pessoal do DC não tem seus usuários arquivo sudoers e tem permissão total.

Agradeço quem puder me dar uma dica.

T+

[8] Comentário enviado por JoseHenriqueRJ em 25/06/2012 - 09:12h

Caro amigo Macbr, por favor, leia o seguinte, acho que vai te ajudar:

Existe no Linux um recurso muito interessante com relação a esse tipo de procedimento (su -, su), no qual o administrador de sistema poderá relacionar os usuários que poderão ou não executar o comando su, sem precisar alterar a permissão do comando.

Trata-se do arquivo suauth, localizado no diretório /etc. Geralmente esse arquivo não vem por padrão com as distribuições, e se vem, está em branco. Caso esse arquivo não exista, utilize o editor de texto de sua preferência para criá-lo. Veja a seguir o formato das linhas deste arquivo, que é bastante simples. Note que são utilizados dois-pontos (:) para separar os campos.

usuário1:usuários:ação

Em usuário1 é especificado o usuário no qual você se “transformará” ao executar o comando su; usuários, indica quem pode realizar esta tarefa, e ação poderá ter 3 valores: OWNPASS (pedir a senha do próprio usuário antes da mudança), NOPASS (não solicitar senha alguma) e DENY (nega o direito à execução do comando).

Para especificar mais de um usuário, separe-os com uma vírgula. Veja o exemplo a seguir:

# /etc/suauth
#
# Arquivo para controlar a execução do comando su no sistema.
root:alguém:OWNPASS
root:apaula,francis,roberta:DENY

Neste exemplo, é concedido ao usuário alguém o direito de executar o comando su para se transformar no superusuário e, para isto, ele deverá informar a sua própria senha (OWNPASS); já para os usuários apaula, francis e roberta é negado o direito de execução do comando su (DENY). Veja a seguir a mensagem apresentada para a usuária apaula, quando ela tenta executar o comando su.

apaula@host:~$ su -
Access to su to that account DENIED.
You are not authorized to su root
apaula@host~$

Já a ação NOPASS é muito perigosa para a segurança do sistema, pois garante o direito de se transformar no superusuário (ou em outro usuário especificado em /etc/suauth) sem a necessidade de digitar senha alguma. Agora, se você deseja que nenhum usuário execute o comando su em seu sistema, o mais prático é alterar sua permissão, deixando-o fora do alcance dos usuários comuns de seu sistema.

[9] Comentário enviado por m4cgbr em 27/06/2012 - 20:55h

JoseHenriqueRJ

Sou muito grato por ter disponibilizado seu tempo e escrever o texto acima de forma tão técnica e detalhada, muito obrigado e que isto seja útil (com certeza será) para outros usuários.

Obrigado por compartilhar.

[10] Comentário enviado por JoseHenriqueRJ em 27/06/2012 - 21:09h


[9] Comentário enviado por macgbr em 27/06/2012 - 20:55h:

JoseHenriqueRJ

Sou muito grato por ter disponibilizado seu tempo e escrever o texto acima de forma tão técnica e detalhada, muito obrigado e que isto seja útil (com certeza será) para outros usuários.

Obrigado por compartilhar.


Caro macbr, obrigado pelo apoio; mas, com certeza, eu que aprendo muito mais aqui.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts