Estou tentando configurar o login automático do ssh usando as chaves rsa no Raspberry PI (raspbian Jesse). Quase tudo que eu encontrar diz para criar chaves na máquina local (ssh-keygen), anexar a chave pública ao arquivo .ssh / authorized_keys do controle remoto e certificar-se de que as permissões do arquivo estejam configuradas para 640 ou 600.
Eu fiz tudo isso, mas ainda sou solicitado por senha quando o ssh'ing.
Eu executei essas ações na máquina local como usuário foo:
~$ cd .ssh
~/.ssh$ ssh-keygen -t rsa (hit enter through all the prompts)
~/.ssh$ cat id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'
[email protected]'s password: //prompted here
De outro terminal que já estava ssh'd para remoto, verifiquei que a chave pública do foo foi anexada ao authorized_keys do bar.
Tentei ssh'ing como usuário foo para remoto como barra de usuário de um novo terminal.
~$ ssh [email protected]
[email protected]'s password: //prompted here
O login automático não funcionou. Então achei este site link . Seguiu as instruções e funciona. Mas isso parece o oposto do que eu pensaria. Esse site diz para criar as chaves no controle remoto e anexar a chave pública ao arquivo authorized_keys do controle remoto, depois baixar a chave privada do controle remoto para a máquina local e usá-la como um arquivo de identidade.
Isso está correto? Por que alguém iria querer cp uma chave privada para outra máquina? Eu pensei que a chave privada deveria permanecer na máquina para a qual ela foi criada e deveria estar protegida.
Aqui estão as instruções para a página vinculada, caso ela se mova
On server:
cd .ssh
ssh-keygen -t rsa (hit return through prompts)
cat id_rsa.pub >> authorized_keys
chmod 600 authorized_keys
rm id_rsa.pub
On client:
cd .ssh
scp myserver.com:.ssh/id_rsa myserver.rsa
chmod 600 myserver.rsa
echo "Host myserver" >> config
echo "Hostname reblets.com" >> config
echo "IdentityFile ~/.ssh/myserver.rsa" >> config
A segunda maneira é (ligeiramente) menos segura, já que a chave privada existe em lugares que ela não precisa - mas ambos fazem a mesma coisa.
Gostaria de saber se você está se deparando com um bug selinux + Redhat / Centos - que geralmente requer a atualização do Centos com o upgrade do yum, e então renomear o sistema de arquivos (reestabelecendo os fixfiles ou similares). Você pode verificar se este é o problema, desativando temporariamente o selinux.
Tags ssh raspbian raspberry-pi