Erro SSH: tipo de chave desconhecido '----- BEGIN'

Estou tendo problemas ao usar chaves autorizadas para efetuar login no SSH em um servidor remoto. As mensagens de erro que eu recebo são assim:

OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx [xxx.xx.xx.xx] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/bfenker/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/bfenker/.ssh/id_rsa type 1
ssh_exchange_identification: Connection closed by remote host

Outras perguntas neste site postaram perguntas semelhantes, e a solução geralmente era verificar novamente todas as permissões no lado do cliente, o que eu fiz:

drwxr-xr-x+ 23 bfenker          staff   782 May  8 11:02 bfenker
drwx------   8 bfenker          staff   272 May  8 10:05 .ssh
-rw-------   1 bfenker  staff  1675 May  8 09:51 id_rsa
-rw-r--r--   1 bfenker  staff   418 May  8 09:51 id_rsa.pub
-rw-------   1 bfenker  staff   999 May  8 09:46 identity
-rw-r--r--   1 bfenker  staff   663 May  8 09:46 identity.pub
-rw-r--r--   1 bfenker  staff   416 May  8 09:06 known_hosts

Eu posso usar a chave autorizada para SSH em outro servidor e deste servidor SSH no servidor que eu quero. Esta é uma solução transitável que estou tentando corrigir, mas acho que também mostra que meu cliente e o servidor estão configurados corretamente.

Observe que, quando eu SSH com êxito em um servidor diferente, recebo as mesmas mensagens de erro, mas parece recuperar a partir das linhas:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0

Alguém sabe por que isso funciona em alguns casos, mas não no caso que eu quero? Qualquer outra sugestão seria muito apreciada!

Necroquestion! Com base no fato de que você pode usar essa chave para fazer login em outro servidor, @ michael-hampton está na trilha correta: existe algo (firewall / tcp wrappers / sshd config) no servidor de destino que está negando acesso. Toda essa conversa sobre formatos de chave incorretos é um arenque vermelho baseado na interpretação incorreta das informações de depuração. A linha

debug1: identity file /Users/bfenker/.ssh/id_rsa type 1

indica que o ssh conseguiu entender a chave.

Sua chave SSH é armazenada no formato errado. O OpenSSH usa chaves que são colocadas em uma única linha. Você precisa ssh-keygencom -ie -mopções, consulte man ssh-keygen. Provavelmente um destes:

ssh-keygen -m RFC4716 -i -f /Users/bfenker/.ssh/id_rsa

Use a saída como novo arquivo de chave ( ssh-keygen ... >newkeyfile).

Editar 1:

Lembre-se do seguinte: "Esta opção lerá um arquivo de chave privado (ou público) não criptografado "

Portanto, provavelmente o arquivo deve ser alterado para um sem senha por um programa que entende esse formato.

Primeiro você deve verificar seus logs sshd. ie

less /var/log/secure

Dependendo do arquivo de distribuição unix com log de segurança, pode ser diferente. Mas quando você descobrir se, deve informar o motivo pelo qual você não pode fazer login.

Eu também enfrentei esse problema recentemente. No meu caso, todas as permissões estavam corretas, incluindo .ssh, o arquivo rsa, o diretório inicial e tudo relacionado ao usuário. O problema era que eu tinha uma chave pública gerada anteriormente em .ssh que não correspondia à chave privada que eu estava usando para fazer login. A remoção da chave pública de .ssh corrigiu o problema.

Eu estava usando ssh-keygen para criar o diretório .ssh que resultou nessa chave de pub e, portanto, no problema.

Eu sinto que as respostas aqui não são muito claras. A resposta de Mark Wagner cobre, mas não explica completamente a situação.

As linhas na saída são prefixadas com seus níveis de depuração, o que também dá uma dica de sua significância: mas números mais baixos são mais significativos. O debug3:material é muito menos importante do quedebug1:

Quando o arquivo de chave é lido, o ssh tenta primeiro analisá-lo como a chave RSA obsoleta (agora chamada de "RSA1"), essas chaves começam com SSH PRIVATE KEY FILE FORMATe um número de versão. As novas chaves RSA são iniciadas -----BEGIN RSA PRIVATE KEY-----. Aqui está uma tentativa de login em que identityexiste uma chave antiga de estilo RSA1 e id_rsaé um novo estilo.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
[...]
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1

Neste ponto, ele identificou os tipos de chave nos arquivos identitycomo type 0e id_rsacomo type 1. Os outros arquivos que ele verifica não existem e são assim type -1.

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3

Como esse é o protocolo 2, a entrada RSA do protocolo 1 identityserá ignorada durante a troca de chaves.

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x5622d77426a0)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))

Aqui, ele nos lembra os principais arquivos que deseja usar. Não sei por que ele não rejeitou os arquivos ausentes, apenas o arquivo do protocolo 1, mas ...

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 372 bytes for a total of 1689
debug1: Server accepts key: pkalg ssh-rsa blen 277

E aqui ele oferece a id_rsachave e é aceito.

Portanto, em resumo, a questão no título da pergunta é um arenque vermelho que vem do ssh tentando várias maneiras de analisar as chaves encontradas, não um problema real com uma chave.

Eu tive o mesmo problema no meu MacBook Pro com MacOS 10.7.5. Não havia nada de errado com minhas chaves, é apenas que elas foram criptografadas (com uma senha, como você deveria fazer) e não estavam sendo criptografadas pelo ssh corretamente. Parece que ssh-agentestá tendo problemas.

De acordo com este artigo , tente o seguinte:

1. Coloque /usr/bin/ssh-agentseus Itens de Login (Preferências do Sistema -> Usuários e Grupos -> selecione usuário -> Itens de Login). Como é muito difícil navegar /usr/binna caixa de diálogo, o artigo sugere criar um link no diretório inicial ( ln -s /usr/bin/ssh-agent) que você pode remover depois de colocá-lo nos itens de login.

2. Saia do Terminal.app

3. Reinicie a máquina.

4. Abra o Terminal e tente novamente o seu comando ssh.

Funcionou para mim (pelo menos uma vez).