3
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 [email protected]:/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.
