SSH Sem Senha

Nível Avançado

Rodrigo Brito
rodrigo_brito@hotmail.com

Resumo

          Segue um passo-a-passo apresentando como é possível estabelecer uma conexão remota shell, sem que seja solicitado uma senha, mas que continue com a segurança adequada. Este procedimento é muito aconselhável para utilização de scripts, como backup, monitoramento, automatização de tarefas, etc.

Palavras-chave

Criptografia, Openssh, chave pública, chave privada, scp, ssh, sshd, ssh-keygen

1. Introdução

          Para conseguir estabelecer uma conexão ssh sem que seja necessária a utilização de uma senha, temos duas opções, a primeira que não possui nenhum tipo de segurança é a autenticação via .rhosts ou simplesmente rsh (remote shell), mas por se tratar de uma conexão que não provêm segurança, deve ser deixada de lado. A segunda opção, utilizar o ssh, essa sim com segurança, pois trata-se de uma conexão criptografada, é a conexão com autenticação de pares de chaves pública e privada de um usuário.

          Lembrando sempre de um fato importante, o conjunto de chaves privada e pública do usuário é diferente da chave de host gerada na primeira conexão entre os dois hosts, e que fica armazenada no arquivo $HOME/.ssh/known_hosts ( levando em consideração que o $HOME é o diretósio do usuário que foi usado na conexão ). Esta chave é gerada, automaticamente, pelo S.O. e fica gravado no arquivo dos dois usuários , tanto no usuário da maquina local como no usário da maquina remota.

          A conexão através de chaves privada e pública, agrega segurança à conexão pelo fato de usar chaves criptografadas. Estas chaves são geradas pela ferramenta ssh-keygen, que, utilizando-se de algoritmos para a criptografia de chaves, como RSA e DSA, que podem gerar chaves com um tamanho mínimos de 64 bytes ( sendo aconselhavel gerar chaves de 128 bytes ou mais, para maior segurança ).

          Será criado uma chave pública e uma chave privada para o usuário que a executou. Estas novas chaves geradas irão ser gravadas nos arquivos $HOME/.ssh/id_rsa ou id_dsa ( Chave privada ) e $HOME/.ssh/id_rsa.pub ou id_dsa.pub ( Chave Pública ).

2. Criando Chaves.

          Tomando de exemplo que a maquina local chama-se "uneb" e que a maquina remota chama-se "college", e que iremos utilizar o usuário Root nas duas maquinas, faremos o seguinte, vamos ter a certeza de que as duas maquinas conseguem se enxergar:

          Usando o comando "ping", e para sabermos se a porta "ssh" está aberta, usamos "nmap -p 22 <host>".

          Tendo certeza que as duas estão no ar, com o serviço "sshd" ativo, procedemos:

          Se tentarmos efetuar uma conexão "ssh" da máquina "uneb" para a máquina "college", verá que nos pede um "password de Root", e veremos que até o final do nosso documento conseguiremos fazer com que este pedido de "password" não exista mais, pelo menos entre conexões ssh do usuário Root da maquina local para o usuário Root da maquina remota. Desconecte da maquina remota digitando <exit> no prompt de comando.

          Agora iremos criar o conjunto de chaves para o usuário da maquina local, digitando o seguinte comando:

[uneb bin]# ssh-keygen -b 1024 -t rsa

          Onde "-b" define o tamanho da chave em bits ( no meu caso, optei por uma chave criptografada de 1024 bits para uma maior segurança ), o -t especifica o tipo de algoritimo de criptografia (no meu caso, RSA), na maioria dos casos utilize o algoritimo RSA pois ele é o default do "ssh". Veremos agora qual é a saida que você irá receber do S.O. em sua tela:

"Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

73:70:9a:ab:cb:f0:96:0a:be:51:69:d1:77:8a:b5:59 root@uneb"
<mailto:root@tonvita>

          Na primeira parte ele pede para você especificar o caminho e o nome do arquivo onde será gravado a chave privada, o caminho que aparece entre parenteses é o default e, ao meu ver, não deve ser modificado. Para que você deixe o caminho default pressione ENTER. Na segunda parte o S.O. pede para que você especifique uma frase para uma identificação de sua chave, porém se você está fazendo este procedimento é porque não quer uma senha para acessar o "ssh" então simplesmente não coloque nada e pressione ENTER, na linha de baixo você deve proceder da mesma forma. Logo abaixo o S.O. especifica o caminho e o nome do arquivo onde estão gravadas a sua senha pública e privada. A última linha contém a sua chave e o usuário para quem ela foi criada.

          Agora uma coisa à ser especificada, é com relação à suas chaves pública e privada, a chave privada é a chave que deve permanecer na maquina local no arquivo do usuário, bem no local onde ela foi gravada pelo "ssh-keygen". A chave pública é a versão de sua chave privada que será gravada nas máquinas remotas que você deseja acessar sem que seja necessária a especificação de uma senha, chaves públicas devem ser gravadas no arquivo do usuário da máquina remota, sendo que o usuário que terá esta chave publica será o usuário correspondente na conexão, ou seja, o usuário que você utilizara para conectar-se a maquina remota. Então vejamos como iremos proceder a partir desta informação, primeiramente vamos verificar os arquivos:

[uneb .ssh]# ls -l

veja se o arquivo id_rsa.pub está contido no diretório ".ssh", ele foi criado a partir do procedimento acima.

          Então, vimos que as nossas duas chaves estão no local correto, vamos agora copiar a chave pública, ou seja, o arquivo id_rsa.pub para o diretório /tmp da máquina remota no caso a máquina "college". Podemos fazer isto utilizando o "ftp" ou "scp". Usarei como exemplo o "scp".

[uneb .ssh]#scp id_rsa.pub root@college:/tmp
id_rsa.pub 100%
|***********************************************| 45 00:00

          Pronto! a chave já foi copiada para a máquina "college".

          Agora estabeleça uma conexão "ssh" com a maquina remota (obs: esta ainda irá necessitar de senha para que seja completa):

[uneb root]# ssh root@college

root@college password: ("Atenção! ainda é obrigatório o uso da senha" )

          Vá ao diretório /tmp da máquina "college" e certifique-se de que seu arquivo de chave pública encontrar-se-a no local, para isso utilize o comando "ls id_rsa.pub".

          Então acrescentaremos o arquivo de /tmp para $HOME/.ssh/authorized_keys, conforme o exemplo abaixo:

[college tmp]# cat id_rsa.pub >> /root/.ssh/authorized_keys

          Vá, novamente, ao diretório do usuário e verifique se o arquivo foi corretamante acrescentado:

[college .ssh]# ls id_rsa.pub
id_rsa.pub
[college .ssh]#

          Desconecte-se do "ssh" e tente estabelecer uma conexão SSH utilizando o usuário que possua a chave privada igual a chave pública da máquina remota, e você vera que a senha não será mais solicitada:

Lembre-se:
uneb: "chave privada"
college: "chave pública"

[uneb root]# ssh root@college
Last login: Wed Oct 8 13:13:07 2003 from root@college
[college root]#

          Pronto conseguimos estabelecer uma conexão "ssh" sem que nos fosse solicitada senha. Mas você se pergunta porque isto é necessário, e eu respondo: pense se você tivesse um script que necessitasse de alguma informação da máquina remota para executar alguma tarefa, você gostária de ficar de babá esperando para colocar alguma senha para que o script funcione, toda vez. Acredito que sua resposta é não, você também não faria a besteira de colocar a sua senha para o acesso remoto a uma máquina em algum script, pois isto colocária em check a sua segurança. Portanto, está é a solução mais segura para este tipo de problema. No meu caso utilizo somente para fazer conexão do "servidor de backup" aos "hosts" da minha Rede, assim meu script roda perfeitamente e ainda está automatizado, sem perder a segurança.

          Uma nota importante, é que não aconselho você a fazer isto com um usuário Root, pois isto é considerado uma grande vulnerabilidade. Mas por que eu fiz o exemplo utilizando o usuário Root? A resposta é simples porque eu fiz este passo a passo utilizando maquinas de teste!

          Outra informação importante não se esqueça de fazer isto apenas com usuários que possuem permissão para executar o "ssh", ou seja, usuários que façam parte do grupo "sshd".

Assuntos relacionados

- OpenSSH

Referência

[OPENSSH] OpenSSH Project, In: http://www.openssh.com
[MAN PAGE] Todas manpage do Openssh, In: man sshd, man ssh, man ssh-add, man ssh-agent, man ssh-keygen, man scp, man sftp-server

Alterações

08 de outubro de 2003 - Termino do documento.
27 de novembro de 2004 - Publicação do documento.