Como entender o ssh-keygen e o ssh-copy-id?

Question

Tanto quanto eu entendo, máquina (A) ssh-keygen gera uma chave, e ssh-copy-id dá essa chave para outra máquina (B), é isso?

Mas quando isso é feito, testar se isso é feito ou não está usando o ssh como: root @ A: ssh root@B Se o login em B sem senha, então isso funciona.

Estou confuso sobre isso. A dá uma chave para B, porque pode um login em B sem senha? Deve ser assim, faça o login em B, B ssh A sem senha.

O meu entendimento está errado?

    

Answer 1

Uma chave ssh tem duas partes, uma parte privada e uma parte pública. É por isso que muitas vezes é chamado de 'par de chaves', um par de chaves que funcionam juntas.

ssh-copy-id copia a parte PUBLIC do par de chaves privada / pública em ~/.ssh/authorized_keys no host remoto.

Qualquer pessoa que tenha a chave privada (e conheça a frase secreta) pode acessar o host remoto sem uma senha.

Para evitar ter que redigitar a frase-senha o tempo todo, você pode usar um programa como ssh-agent para manter as chaves privadas para você (em termos simples, ele armazena em cache a chave privada depois de desbloqueá-la com o passphrase). Ele manterá a chave privada até que você diga que não, ou você mata o agente ou logout. veja man ssh-agent .

A parte PUBLIC do par de chaves não é particularmente sensível, em termos de segurança. Pode ser distribuído e divulgado sem risco. Sem a chave privada correspondente (e a frase secreta da chave privada), é praticamente inútil.

A porção PRIVATE do par de chaves, é claro, deve ser mantida em segredo.

    

Answer 2

O que você está perdendo é que ssh-copy-id não copia apenas a chave pública para B: adiciona a chave pública à lista de chaves que permitem o acesso à conta ( ~/.ssh/authorized_keys ). Depois de executar ssh-copy-id , a chave não é apenas armazenada em B em algum lugar, ela é registrada em B como um método de login autorizado.

A chave privada está em A e precisa ser passada para o cliente SSH (isso pode ser feito permitindo que ela procure ~/.ssh/id_* , passando uma opção de linha de comando -i , usando IdentityFile in ~/.ssh/config , ou via ssh-agent ). A chave pública está em ~/.ssh/authorized_keys em B. Quando você faz o login em B de A, o cliente SSH envia uma prova de posse da chave privada para B; B vincula essa prova de posse a uma chave pública encontrada em ~/.ssh/authorized_keys para autorizar a tentativa de login.

    

Answer 3

A gives a key to B, why can A login on B without password?

Você está certo.

Quando o SSH recebe uma conexão de entrada, ele pode autenticar o usuário de várias maneiras. Isso é configurável. Uma maneira típica é verificar se o usuário tem uma chave pública em um arquivo ~ / .ssh / authorized_keys * e aceitar uma chave privada correspondente (supondo que todos os detalhes sejam aceitos, como um arquivo com permissões aceitáveis). Se nenhuma chave estiver configurada ou se o cliente SSH falhar em fornecer detalhes que comprovam que o cliente SSH tem uma chave privada correspondente, o servidor SSH solicitará uma "senha" (ou "senha").

ssh-copy-id é basicamente um comando que faz uma tarefa que não é muito difícil de fazer manualmente. Ele usa o SSH para se conectar ao sistema remoto e obtém a chave pública no arquivo ~ / .ssh / authorized_keys *.

Depois que aprendi a usar o ssh-copy-id, eu rapidamente me esqueci, porque o programa não era muito útil para mim, já que eu já aprendi a fazer manualmente as tarefas equivalentes. Usar ssh-copy-id era, reconhecidamente, um pouco mais fácil / rápido. No entanto, era muito não essencial. Acredito que se a conveniência extra vale o esforço para aprender mais um comando, é questionável.

ssh-copy-id pode exigir que o usuário insira uma senha, da mesma forma que o usuário precisaria fazer (usando qualquer outro cliente SSH) se o usuário estivesse fazendo isso manualmente. Não contorna os requisitos normais de autenticação.

(Obviamente, depois que o ssh-copy-id faz sua parte, a chave SSH é instalada e pode ser usada facilmente.)

It should go like this, login on B, B ssh A without password.

Você pode fazer logon no B (usando uma senha) e, em seguida, usar o SSH (como um shell ou um protocolo que usa SSH, como o SCP / SFTP) para obter uma chave do A. Sim, isso também funciona. Se você precisa de uma senha ou não, isso depende da configuração de A. Se A tiver uma chave pública e B tiver uma chave privada correspondente, B talvez não precise digitar uma senha.

a resposta do cas menciona o ssh-agent (que não foi especificado na pergunta). Isso é basicamente outra abordagem. O agente ssh armazena chaves privadas. Eles podem ser criptografados, portanto, você precisa digitar uma frase secreta para obter acesso às chaves privadas descriptografadas. Quando você executa o SSH, o servidor SSH fará algo que o agente ssh reconhece e, em seguida, o agente ssh poderá fornecer os detalhes necessários ao servidor SSH. A idéia é que, uma vez que o agente ssh esteja configurado, depois de digitar sua senha uma vez (para descriptografar o acesso às chaves), você pode fazer conexões diferentes durante todo o dia e não precisar continuar digitando novamente sua frase longa. como o ssh-agent está em execução. Isto é principalmente sobre a experiência do usuário final que usa o cliente SSH, então não há muito trabalho que você precisa fazer no servidor SSH (além de configurar uma chave pública, assim como qualquer um dos outros métodos que já foram discutidos).