Como usar ssh, scp e rsync sem digitar senha

De BCC Wiki

Convenções

Vamos supor que vc está no seu micro de casa (chamado de casa) e quer logar em outro qualquer (chamado remoto). Os domínios serão casa.com.br e remoto.com.br.

Como executar o SSH

Para utilizar, de casa, execute no shell:

ssh [email protected]

Se o nome de usuário for o mesmo tanto na sua casa quanto no micro remoto, basta:

ssh remoto.com.br

Para usar compressão de dados:

ssh -C remoto.com.br

Para executar programas gráficos no micro remoto e exibílos no seu (lento, mesmo usando compressão):

ssh -CX remoto.com.br

Não digitar senhas, aumentando a segurança!

1. No micro da sua casa:
   • Verifique se vc tem o arquivo ~/.ssh/id_rsa.pub (esse é o nome default, pode ser que tenha outro parecido, mas é importante ter certeza de que é a chave pública). Se não tiver (arquivo e/ou diretório), execute

     ssh-keygen -t rsa

     e tecle enter em todas as perguntas (não defina senha alguma).
2. No micro remoto:
   • Abra o arquivo ~/.ssh/authorized_keys (se não existir, crie) e acrescente nele o conteúdo de id_rsa.pub do micro da sua casa. Se não quiser fazer "cut & paste", execute (última vez com senha):

     cat ~/.ssh/id_rsa.pub | ssh user@remoto 'cat - > .ssh/authorized_keys'

Pronto! Para testar, saia do micro remoto e entre novamente. Todos os programas que utilizam o SSH também não pedirão senha, como por exemplo o scp e o rsync. Não seja tão apressado, leia pelo menos a conclusão

Teoria

Graças ao EP de 110 fica mais simples de entender, afinal trata-se do algorítmo RSA (default do SSH). Para relembrar, qualquer pessoa pode conhecer sua chave pública e encriptografar mensagem que só você, através de sua íntima chave privada, poderá descriptografar.

Ao utilizar as chaves no SSH ao invés de digitar a senha, a segurança aumenta, pois a senha seria transmitida encriptografada, mas é descriptografada no servidor e vulnerável a trojan horses dele). A autenticação por chaves funciona da seguinte maneira:

1. Casa: você pede para logar em remoto.com.br;
2. Casa: seu micro recebe a chave pública do remoto (além dos usuários, o computador tem as chaves dele) e faz uma das três coisas:
   • Se a chave de remoto.com.br não for conhecida, ele pergunta se você quer adicioná-la à lista de chaves conhecidas (~/.ssh/known_hosts - contém uma relação de endereços e suas chaves públicas).
   • Se já tiver uma chave armazenada para remoto.com.br e for a mesma, segue para o próximo passo;
   • Caso a chave armazenada seja diferente, seu SSH avisa que o endereço remoto.com.br pode pertencer agora a outro micro. Isto pode ser um ataque, o famoso Man-in-the-middle.
3. Casa: aceitada a chave pública de remoto.com.br, você envia a sua pública para ele.
4. Remoto: se a chave estiver em authorized_keys, ele encriptografa algo aleatório com ela e manda pra você o resultado (se não, pede senha);
5. Casa: com a chave privada, seu micro descriptografa o que remoto mandou, encriptografa com a chave pública de remoto e envia de volta para ele;
6. Remoto: com a chave privada dele, o que você enviou é descriptografado e, caso o resultado bata com aquilo que ele gerou aleatoriamente, você conseguirá se logar.

Man-in-the-middle attack

O micro onde você está tentando conectar pode não ser aquele que você queria. Há um destemível homem no meio do caminho que desviou sua rota virtual para outro micro, que provavelmente está configurado para pegar suas senhas e tudo mais o que você digitar :-O

Mas calma! Seu amigo SSH, ao perceber que a chave pública do micro remoto mudou, não deixa você se logar nele! Mas algumas vezes você tem certeza de que realmente se trata do micro certo. Vejamos os dois casos.

É um ataque!

Tome muito cuidado. Lembro que na TV passou uns caras que invadiram o DNS de um provedor (o DNS traduz o endereço alfanumérico de máquinas em IPs - os nomes google, wikipedia, etc, são apenas abstrações ;-) ) e aplicaram um golpe transparente aos usuários daquele DNS: fizeram www.umbancoqualquer.com.br apontar para o IP de uma máquina configurada por eles para exibir uma página de internet banking clonada, que enviava os dados de login para os golpistas e, em seguida, redirecionava o usuário para a página verdadeira do banco, sem que este notasse. A idéia foi muito boa e não me recordo como eles foram pegos, acho que alguém suspeitou da aparência da página inicial, ou eles tiveram que enviar a pessoa para o site de login mais uma vez (porém verdadeiro) e alguém percebeu, sei lá.

No SSH, isso não acontece, pois, para começar, ele compara a chave pública do remoto com outra da lista logo no início. A pública, é fácil obter, mas a privada deve ser bem guardada e sua ausência ou troca impossibilitará a última etapa explicada em Teoria.

Não é um ataque!

Vou dar um exemplo que aconteceu no IME. Semestre passado (primeiro de 2006) o epicurus, também conhecido por shell.linux.ime.usp.br, passou por uma manutenção e acabou ficando com outras chaves. Infelizmente não reinstalaram a chave antiga através de backups (/etc/ssh/ssh_host_rsa_key - privada e só o root lê, já chequei ;-) - e /etc/ssh/ssh_host_dsa_key.pub). Resultado: pessoas chorando no CEC por não conseguirem logar na rede linux :-) .

Neste caso, após saber de que não se trata de um ataque, deve-se apagar a linha que contém shell.linux.ime.usp.br em ~/.ssh/known_hosts do seu micro e então tentar logar novamente, aceitando a nova chave.

Conclusão

Três mandamentos:

1. Utilize as chaves: é mais prático e mais seguro;
2. Tenha backups das suas chaves (id_rsa e id_rsa.pub);
3. Cuidado para não esquecer suas senhas, afinal você vai digitá-las com menos freqüência :-)

Mas se você for assaltado e levarem seu computador, apague sua chave pública de cada authorized_keys que você alterou! A não ser que seu HD seja encriptografado, mas isso já é outro assunto... ;-)

Bibliografia

http://www.kuro5hin.org/story/2001/10/21/134817/35