
Estou tentando aprender isso em vez de apenas seguir os guias para poder recomendar ações adequadas quando as pessoas perguntarem (e o fazem). Aqui está o que eu descobri.
Primeiro, gere ambas as chaves com um comando como este:
ssh-keygen -b 2048 -t rsa -C comment -f ~/.ssh/id_rsa
Em seguida, você envia a parte pública da chave para o arquivoauthorized_keys2
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
(e então chmod para 600 ou similar)
E você baixa a chave privada para o seu computador (id_rsa) e a alimenta no Putty para ser lida e autenticada.
Estas são as etapas corretas para configurar esta autenticação de chave pública/privada para login sem senha no SSH?
Responder1
Embora as etapas que você descreveu funcionem, há um problema. Você está gerando o par de chaves no computador de destino (remoto) e, em seguida, baixando o arquivo de chave privada para o seu sistema local. Existem implicações de segurança aqui que você não deve ignorar:
- Se o controle remoto já estiver comprometido, alguém pode ter pego sua senha.
- Se o sistema remoto for comprometido no futuro, o invasor terá acesso ao seu arquivo de chave privada (e o luxo de usar um ataque de força bruta offline para tentar descriptografá-lo).
Como você está usando pares de chaves ssh para (tentar) resolver alguns dos problemas inerentes à autenticação de senha, geralmente você deseja fazer as coisas desta maneira:
Gere o par de chaves em seu sistema local. Idealmente, a chave privada (a) nunca será armazenada em um sistema de arquivos compartilhado (por exemplo, diretório inicial do NFS) e (b) nunca será armazenada em um computador que permita logins remotos.
Publique a chave pública em todo o mundo. Eu mantenho minhas chaves públicas em um site para poder obtê-las sempre que precisar. Coloque a chave pública nos
authorized_keys
arquivos apropriados nos sistemas aos quais você se conectará.
Se você for especialmente paranóico, poderá armazenar sua chave privada em um pen drive e usá-lo apenas para carregar a chave em um arquivo ssh-agent
. Neste ponto, você não precisa mais do arquivo de chave real.
Responder2
Talvez seja melhor gerar a chave no(s) sistema(s) cliente(s). Você pode acabar com um arquivo autorizado_keys maior, mas é mais fácil desabilitar um sistema comprometido. Se você migrar a chave privada do servidor, precisará regenerar e migrar a chave para todos os sistemas clientes. Cada cliente deve ter sua própria chave.
Putty usa puttygen
para gerar a chave. puttygen
também fornecerá a chave pública no formato correto para colar no sistema cliente. É melhor proteger a chave com uma senha se ela estiver sendo usada para acesso de login. Pageant
ou ssh-agent
pode ser usado para manter a chave desprotegida na memória para que a senha não precise ser digitada novamente em cada conexão.
Depois de adicionar uma chave e definir a proteção, você poderá adicionar chaves adicionais com a necessidade de redefinir as permissões. Normalmente carrego a chave pública do sistema com um nome como example.pub
onde exemplo é o nome do sistema ao qual a chave pertence.
Muitas implementações voltaram a ser usadas authorized_keys
como arquivo-chave. Este arquivo pode ser usado para restringir o sistema do qual a chave será aceita, forçar a execução de um comando, limitar o acesso e outras coisas. Veja a man
página para mais detalhes.
Em alguns casos, pode ser útil ter múltiplas chaves no sistema cliente. Isso pode ser feito para oferecer suporte a processos em lote executados com chaves que não possuem senha.
Responder3
Isso parece bom. Muitas pessoas fariam isso na direção oposta (gerar a chave localmente e depois enviá-la .pub
para o servidor), mas qualquer uma delas pode funcionar.