Português do Brasil English
Devin no Facebook  Devin no Twitter  RSS do Site 
Servidores    

SSH – Muito mais que um simples shell seguro


Comentários  3
Visualizações  
18,405

Para quem administra vários servidores, hoje em dia o ssh faz-se mais do que necessário para agilizar a execução de comandos remotos. Entretanto, já presenciei diversas cenas em que determinado usuário não sabe o poder que o ssh nos oferece e acaba utilizando-o apenas como uma simples ferramenta para login remoto, deixando de lado outras poderosas funcionalidades.

O intuito deste tutorial é mostar algumas funcionalidades do ssh, que ajudam e muito no dia-a-dia do administrador.

1. Troca de Chaves

Certa vez um aluno me contou que queria criar um script de backup remoto utilizando o ssh (scp), porém não estava conseguindo fazer o script ler um arquivo com a senha (gravada em texto-plano) e inserí-la na hora em que o ssh pede a senha do usuário. Então perguntei para ele:

- Por que você quer utilizar o SSH ao invés de FTP?
- Porque é mais seguro.
- O que tem de seguro em colocar a senha em texto-plano dentro de um arquivo?
- …

Ele não soube o que responder. Falei pra ele utilizar a troca de chaves. Com esse método, as máquinas possuem uma chave pública e uma chave privada que podem ser geradas com o comando ssh-keygen. Neste tutorial estaremos utilizando um usuario chamado “usuario” para executar todo o procedimento, mas isso não impede de você utilizar qualquer usuário ou até o root. Mas nesse caso, lembre-se sempre de substituir os diretórios HOME quando houver referência e o próprio nome de usuário.

Primeiro gere as chaves da seguinte forma:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): # Aqui ele pergunta onde você quer gerar a chave
Enter passphrase (empty for no passphrase):                      # Aqui ele pergunta se quer senha na chave (deixe em branco)
Enter same passphrase again:                                     # Aqui ele confirmação da senha (deixe em brando novamente)
Your identification has been saved in /home/usuario/.ssh/id_rsa.
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub.
The key fingerprint is:
b3:12:2e:9b:b7:9b:56:f2:ba:fa:d7:71:74:74:99:b2 usuario@desktop-brandao

No final, dá para ver que ele mostra onde gravou as chaves pública e privada.

Este comando deve ser executado na maquina cliente, neste caso a máquina que vai enviar os arquivos. Verificando o arquivo ~/.ssh/id_rsa.pub (no cliente), teremos algo parecido com o exibido abaixo:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Esta é apenas uma linha, quebramos em várias linhas para melhor visualização neste tutorial).

Esta é a chave pública que deve ser adicionada no servidor, no arquivo definido na tag “AuthorizedKeysFile” na configuração /etc/ssh/sshd_config do servidor. Por padrão, este arquivo é o “authorized_keys” dentro do diretório .ssh (notem o ponto) no HOME de cada usuário. Neste exemplo vamos definir a tag AuthorizedKeysFile para utilizar o arquivo /etc/ChavesSSH. Utilizando um editor de texto de sua preferência, acesse o arquivo /etc/ssh/sshd_config e deixe a linha do AuthorizedKeysFile como a seguir:

AuthorizedKeysFile    /etc/ChavesSSH

Reinicie o ssh para que as novas configurações sejam aplicadas:

/etc/init.d/sshd restart

Após isso, no servidor, crie o arquivo /etc/ChavesSSH e adicione a chave tirada do arquivo ~/.ssh/id_rsa.pub que está no cliente. Você pode copiar e colar ou transferir o arquivo via scp e concatená-lo (recomendado). No caso de transferir e concatenar, faça algo parecido com isto:

maquina-cliente$ scp ~/.ssh/id_rsa.pub usuario@192.168.0.254:/home/usuario
Enter password: <digite a senha>
[...]

maquina-servidor# cat /home/usuario/id_rsa.pub >> /etc/ChavesSSH

(Lembrando de substituir o 192.168.0.254 pelo IP remoto do servidor).

Ao fazer isto, a chave do cliente estará dentro do arquivo de chaves autorizadas à fazer logins na conta, ou seja, se você tiver a chave privada (~/.ssh/id_rsa) correspondente, poderá se logar com qualquer usuário no sistema remoto. Na máquina cliente, execute o comando:

$ ssh <IP do servidor> -l root

Pronto, você verá que se logou na máquina servidor sem precisar digitar senha :)

Você também pode incrementar esta configuração. Por exemplo, se você quiser que esta chave só seja aceita se partir de uma determinada origem de IP (Ex.: 192.168.0.1), você pode adicionar no arquivo /etc/ChavesSSH a opção “from”, como mostrado na linha a seguir:

from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Mais uma vez, lembre-se que esta é apenas uma linha

Repare que apenas foi adicionada a opção from=”192.168.0.1″ no inicio da linha.

Outra opção legal é limitar a utilização do usuário apenas à comandos, evitando assim que o usuário ganhe uma shell na máquina. Deste modo, o usuário poderá apenas executar comandos remotos ou utilizar o scp para transferência de arquivos. A configuração é simples, basta adicionar a opção no-pty no início da linha no /etc/ChavesSSH, deixando-a como a seguir:

no-pty,from="192.168.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwN3WxdXANQxGW+gev3yrQKFzdpyuypmJGRQh6k
khB+axeCf/oQQTopHQPSJDpMtrWAXK8ZrYSlOgtLZQjjk0U1UDzYJ1Qcpq9Fh9b8NQBZLYuYimbFHuo
HZ1VGgmVkoaAQ31bKuaIK9Z2LvnR+YKPH6hPaDS9lCyW0xRAT4xSvK8S7ZrozEZUjQZ4+IMNN/yu5+
zalIzZyqXlRcDk+lV8PfR9p0EXQTaKRrNJz+sD6Yld5Ty7igd6bsGNa/pK6rxY0FLnPX/u4xjmDU1m
VNgFJ8zNcb6ibzv4IUk9xhVRDJKgW4xSNN7LEe2asjVXJ87UU/hkUGTLNGwg5c4hFWZ1w== usuario@desktop-brandao

(Mais uma vez, lembre-se que esta é apenas uma linha

Note que também foi adicionada uma vírgula entre a tag no-pty e a tag from, ou seja, você pode combinar várias opções separando-as com vírgula.

Outras opções legais para se adicionar no arquivo de chaves podem ser obtidas na sessão 8 do man do sshd:

$ man 8 sshd

2. Configurações avançadas

O arquivo sshd_config oferece diversas opções que podem nos ajudar no dia-a-dia. Coloquei aqui as opções que mais me chamam atenção.

2.1. Port

Utilidade: A opção port serve para definir em qual porta o daemon do ssh (sshd) aceita novas conexões.

Comentário: Apesar de muitas pessoas acreditarem que trocando a TAG Port para uma outra porta estarão assegurando que o ssh ficara seguro, isso apenas causa uma falsa impressão de segurança, pois utilizando um simples port-scanning com o nmap ou programas similares, podemos verificar em que porta o daemon está escutando e qual a versão do serviço, utilizando a opção -sV

Exemplo:

# nmap localhost -sV
222/tcp  open  ssh         OpenSSH 4.7 (protocol 2.0)

Veja que mesmo estando na porta 222, o nmap conseguiu ver que o serviço rodando na porta é o ssh.

2.2. ListenAddress

Utilidade: Esta opção é útil para definir um endereço IP específico em que o daemon ficará escutando no servidor, caso o servidor possua mais de uma interface de rede (física ou virtual).

Comentário: Esta opção é legal para servidores que ficam ligados diretamente a Internet, pois você pode definir que o daemon do ssh aceitará somente conexões oriundas da sua rede local.

Exemplo:

ListenAddress    192.168.0.254

2.3. LogLevel

Utilidade: Esta opção nos oferece diversos níveis de log para analisarmos.

Comentário: Os níveis disponíveis nesta opção são as seguintes: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, e DEBUG3. A opção que vem habilitada por padrão é a INFO, porém a que mais me chama a atenção é a DEBUG, que fornece todas as informações de possamos desejar.

2.4. PermitRootLogin

Utilidade: Esta opção serve para permitir ou não que o usuário root possa se logar via ssh.

Comentário: Esta opção é legal para evitar ataques de força bruta, pois o usuário root existe em qualquer sistema Linux/Unix e a maioria das tentativas de invasão tentam se logar como root.

2.5. AllowGroups

Utilidade: Esta opção nos permite estabelecer um grupo de usuários que poderão efetuar login via ssh.

Comentário: Esta opção é muito legal para definir, por exemplo, um grupo de administração do servidor e permitir o login via ssh somente dos usuários pertencentes à um certo grupo.

Exemplo:

AllowGroups    admin

2.6. AuthorizedKeysFile

Utilidade: Como visto no primeiro tópico deste tutorial, esta opção é utilizada para definir o arquivo com as chaves públicas dos usuários que poderão efetuar login sem precisar digitar a senha.

Comentário: Esta opção é muito útil para pessoas que administram muitos servidores com senhas diferentes, ao invés de ter que decorar todas as senhas ele pode exportar a sua chave pública e efetuar o login via troca de chaves. Por padrão este arquivo vem definido como ~/.ssh/authorized_keys, porém você pode definir qualquer arquivo como arquivo de chaves, como vimos no primeiro tópico deste tutorial.

Termino por aqui e espero que este tutorial seja útil.


Comentários  3
Visualizações  
18,405


TagsLeia também


Leia também



Comentários

3 respostas para “SSH – Muito mais que um simples shell seguro”

  1. Sem falar que tunel por SSH é uma mão na roda para navegação anônima e quem não quer usar VPN.

  2. pauloriccelli disse:

    Muito bom! Fazia algum tempo que eu não lia algo tão bom. Parabéns e continue assim.

  3. Marco Antonio disse:

    Excelente tutorial, ja adicionei o site nos marcadores (favoritos).

Deixe uma resposta