Minha resposta é que usar pares de chaves públicas é muito mais sábio do que usar senhas ou listas de senhas. Vou me concentrar em coisas que não são amplamente conhecidas sobre as diferentes formas de autenticação SSH e não vejo outras respostas mencionando-as.
Em primeiro lugar, você deve entender que a autenticação do usuário é um processo diferente e separado do estabelecimento do canal seguro . Em termos leigos, isso significa que primeiro, a chave pública do servidor é usada (se aceita!) Para construir o canal SSH seguro, permitindo a negociação de uma chave simétrica que será usada para proteger a sessão restante, habilite o canal confidencialidade, proteção de integridade e autenticação do servidor.
Depois que o canal estiver funcional e seguro, a autenticação do usuário ocorre. As duas formas usuais de fazer isso são usando uma senha ou um par de chaves públicas. A autenticação baseada em senha funciona como você pode imaginar: o cliente envia sua senha pelo canal seguro, o servidor verifica se essa é realmente a senha do usuário específico e permite o acesso. No caso da chave pública, temos uma situação muito diferente. Nesse caso, o servidor possui a chave pública do usuário armazenada. O que acontece a seguir é que o servidor cria um valor aleatório (nonce), criptografa-o com a chave pública e o envia ao usuário. Se o usuário for quem deveria ser, ele pode descriptografar o desafio e enviá-lo de volta ao servidor, que então confirma a identidade do usuário. É o modelo de desafio-resposta clássico. (Em SSHv2, algo um pouco diferente, mas conceitualmente próximo, é realmente usado)
Como você pode imaginar, no primeiro caso a senha é realmente enviada para o servidor (a menos que o SSH use uma resposta de desafio de senha), no segundo, sua chave privada nunca sai do cliente. No cenário imaginário em que alguém intercepta o tráfego SSL e é capaz de descriptografá-lo (usando uma chave privada de servidor comprometida ou se você aceitar uma chave pública errada ao se conectar ao servidor) ou tem acesso ao servidor ou cliente, sua senha será conhecido - com a autenticação de chave pública-privada e o modelo de resposta de desafio, seus detalhes privados nunca cairão nas mãos do invasor. Portanto, mesmo que um servidor ao qual você se conecta esteja comprometido, outros servidores para os quais você usa a mesma chave não serão !
Existem outras vantagens de usar um par de chaves públicas: A chave privada não deve ser armazenada em texto não criptografado em seu PC cliente como você sugere. Isso, obviamente, deixa o arquivo da chave privada aberto para comprometimento, como faria um arquivo de senha não criptografado, mas é mais fácil de descriptografar (no login) e usar a chave privada. Deve ser armazenado criptografado e precisa que você forneça uma frase-senha geralmente longa para descriptografá-la cada vez que for usada.
Claro, isso significa que você terá que fornecer uma frase longa frase-senha cada vez que você se conectar a um servidor, para desbloquear sua chave privada - Existem maneiras de contornar isso. Você pode aumentar a usabilidade do sistema usando um agente de autenticação: Este é um pedaço de software que desbloqueia suas chaves para a sessão atual, quando você faz login no gnome, por exemplo, ou quando você faz o ssh em seu cliente, então você pode apenas digite 'ssh remote-system-ip' e efetue login, sem fornecer uma senha longa, e faça isso várias vezes até que você saia da sessão.
Então, para resumir, usar pares de chaves públicas oferece consideravelmente mais proteção do que usar senhas ou listas de senhas que podem ser capturadas se o cliente , o servidor ou a sessão segura está comprometida . No caso de não usar uma senha longa (o que não deveria acontecer), ainda assim os pares de chaves públicas oferecem proteção contra sessões e servidores comprometidos.