O que esse erro ssh significa?

Este é meu último recurso. Eu tenho tentado descobrir o problema aqui por horas.

O negócio é o seguinte: copiei minha chave privada da máquina 1 para a máquina 2. A máquina nº 1 é capaz de se conectar via ssh a um servidor com minha chave pública, mas a máquina nº 2 fornece a seguinte saída ao tentar se conectar ao servidor:

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa user@192.168.1.244 -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

...


Permission denied (publickey).

Obviamente, há mais saída de depuração que eu omiti e posso fornecer mediante solicitação. No entanto, estou convencido de que ele não gosta do meu arquivo de chave privada.

Eu também suspeitava que isso tivesse a ver com como eu o copiei da máquina 1 para a máquina 2. Copiei / colei o texto da chave privada em uma unidade flash. Esse pode ser o problema, no entanto, quando eu dupliquei esse método em outro arquivo de chave privada em funcionamento, e fiz uma comparação do original com o arquivo copiado / colado, eles são idênticos.

Eu tenho lutado com isso. Se eu pudesse obter um pouco mais de informação sobre por que ela não gosta da minha chave, eu poderia corrigi-la, tenho certeza. Alguém tem alguma ideia sobre isso? Existe algum metadado em algum lugar que diga ao ssh que um arquivo é de fato uma chave RSA?

Na minha experiência, os dois erros de autenticação mais comuns baseados em chaves são

1. Permissões inapropriadamente amplas no $HOME/.sshdiretório
2. Um erro ao copiar a chave pública para o sistema remoto

Permissões de arquivo

O OpenSSH faz muito na tentativa de proteger você de si mesmo. A maneira que mais afeta o usuário é impor restrições rígidas sobre quem tem acesso à sua pasta ssh local. Você realmente deseja apenas que você, e somente você, acesse o diretório. Bem, e qualquer pessoa com uid = 0, mas não há uma maneira boa de contornar isso. Portanto, o que você precisa fazer é simplesmente alterar suas permissões: chmod -R go-rwx ~/.sshIsso removerá os direitos de leitura, gravação e execução de todos os arquivos abaixo do diretório .ssh de todos os usuários, exceto o proprietário, ou seja, você .

Problemas de chaves autorizadas

O arquivo que contém sua chave pública geralmente $HOME/.ssh/authorized_keystem que caber em um formulário muito específico para o SSH entender como aceitar a chave privada. Cada chave deve consistir em, pelo menos, 2 campos

1. Tipo de chave usada (RSA, DSA, RSA1, etc)
2. Chave

Cada chave, juntamente com todas as suas opções e partes componentes, deve ser listada uma por linha neste arquivo. Como as teclas tendem a ser muito longas, elas geralmente quebram e aparecem como duas linhas no seu terminal. Às vezes, isso causa estragos ao tentar copiar / colar, pois algumas vezes uma ou mais novas linhas são inseridas onde quer que a chave seja inserida na tela. Corrigir esse problema pode ser um pouco mais complicado para um iniciante em shell.

Tente executar
wc -l ~/.ssh/authorized_keys
Isso imprimirá o número de linhas no arquivo. Compare esse número com o número de chaves que você espera estar no arquivo. Se você aceitará apenas essa chave única, também poderá fazer uma cópia do arquivo de chave pública, pois ele tem o mesmo formato do arquivo de chaves autorizado. Algo como
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
ou, se você tiver sua chave pública no mesmo sistema, poderá fazer
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

Além disso, consulte o arquivo de log no host remoto e veja se há algum erro sendo relatado lá. Os arquivos provavelmente serão /var/log/secure.logou /var/log/auth.

No entanto, você provavelmente precisará gerar um novo par de chaves para a máquina 2 se conectar ao servidor. Freqüentemente, a chave pública lista o nome do usuário e da máquina daqueles que os geraram. Isso deve ficar aparente no seu arquivo allowed_keys no servidor.

As mensagens de depuração fornecidas significam que um arquivo de chave privada é lido com a suposição de que na verdade é um arquivo de chave pública / hosts autorizados. Isso pode não ser um erro fatal (eu recebo essas mensagens mesmo para conexões de trabalho). Diz alguma coisa sobre "Oferta" ou "enviamos"?

Tente comparar os arquivos de configuração ssh entre os dois servidores.

ie algo como cat / etc / sshd_config