Ошибка SSH: неизвестный тип ключа '----- BEGIN'

У меня проблемы с использованием авторизованных ключей для входа по SSH на удаленный сервер. Сообщения об ошибках, которые я получаю, выглядят так:

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

Другие вопросы на этом сайте опубликовали аналогичные вопросы, и решение обычно заключалось в двойной проверке всех разрешений на стороне клиента, что я и сделал:

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

Я могу использовать авторизованный ключ для SSH на другой сервер и с этого сервера SSH на сервер, который я хочу. Это обходной путь, который я пытаюсь исправить, но я думаю, что он также показывает, что и мой клиент, и сервер настроены нормально.

Обратите внимание, что когда я успешно подключаюсь по SSH к другому серверу, я получаю те же сообщения об ошибках, но кажется, что восстановление начинается со строк:

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

Кто-нибудь знает, почему это работает в некоторых случаях, но не в том случае, если я хочу? Любые другие предложения будут высоко оценены!

Necroquestion! Исходя из того, что вы можете использовать этот ключ для входа на другой сервер, @ michael-hampton находится на правильном пути: на конечном сервере есть что-то (firewall / tcp wrappers / sshd config), которое запрещает доступ. Все эти разговоры о неправильных форматах ключей - это красная сельдь, основанная на неправильной интерпретации отладочной информации. Линия

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

указывает, что ssh смог понять ключ.

Ваш ключ SSH хранится в неправильном формате. OpenSSH использует ключи, которые помещаются в одну строку. Вам нужно ssh-keygenс -iи -mварианты см man ssh-keygen. Вероятно, один из них:

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

Используйте вывод как новый ключевой файл ( ssh-keygen ... >newkeyfile).

Изменить 1:

Пожалуйста, обратите внимание: «Эта опция будет читать незашифрованный файл закрытого (или открытого) ключа»

Поэтому, вероятно, файл должен быть изменен на файл без ключевой фразы программой, которая понимает этот формат.

Я чувствую, что ответы здесь не очень ясны. Ответ Марка Вагнера действительно охватывает это, но не полностью объясняет ситуацию.

Строки в выходных данных имеют префикс с уровнями отладки, что также указывает на их значимость: но более низкие числа более значимы. Материал debug3:гораздо менее важен, чемdebug1:

Когда файл ключа считывается, ssh сначала пытается проанализировать его как устаревший ключ RSA (теперь называется «RSA1»), эти ключи начинаются с SSH PRIVATE KEY FILE FORMATномера версии. Все новые ключи RSA запускаются -----BEGIN RSA PRIVATE KEY-----. Вот попытка входа, где identityстарый ключ стиля RSA1 и id_rsaновый стиль.

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

На данный момент он определил типы ключей в файлах identityкак type 0и id_rsaкак type 1. Другие файлы, которые он проверяет, не существуют и, таким образом, существуют 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

Поскольку это протокол 2, ключ RSA протокола 1 identityбудет игнорироваться во время обмена ключами.

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))

Здесь это напоминает нам о ключевых файлах, которые он хочет использовать. Не уверен, почему он не отклонил отсутствующие файлы, только файл протокола 1, но ...

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

И вот он предлагает id_rsaключ, и это принято.

Итак, короче говоря, проблема в названии вопроса - красная сельдь, возникающая из-за того, что ssh пытается несколькими способами проанализировать найденные ключи, а не настоящая проблема с ключом.

Сначала вы должны проверить ваши логи sshd. т.е.

less /var/log/secure

В зависимости от дистрибутива unix файл с журналом безопасности может отличаться. Но когда вы обнаружите, если это, следует указать причину, по которой вы не можете войти.

Я также столкнулся с этой проблемой недавно. В моем случае все разрешения были правильными, включая .ssh, файл rsa, домашний каталог и все, что связано с пользователем. Проблема заключалась в том, что у меня был ранее сгенерированный открытый ключ в .ssh, который не соответствовал закрытому ключу, который я использовал для входа в систему. Удаление открытого ключа из .ssh решило проблему.

Я использовал ssh-keygen для создания каталога .ssh, что привело к этому ключу публикации и, следовательно, к проблеме.

У меня была такая же проблема на моем MacBook Pro с MacOS 10.7.5. В моих ключах не было ничего плохого, просто они зашифрованы (с парольной фразой, как вы и должны делать) и не были правильно зашифрованы с помощью ssh. Кажется, что ssh-agentесть проблемы.

В соответствии с этой статье , попробуйте это:

1. Положил /usr/bin/ssh-agent свои элементы входа в систему (Системные настройки -> Пользователи и группы -> выберите пользователя -> Элементы входа в систему). К нему очень трудно перейти /usr/binв диалоговом окне, поэтому в статье предлагается сделать ссылку в вашем домашнем каталоге ( ln -s /usr/bin/ssh-agent), которую вы можете удалить, поместив ее в элементы входа в систему.

2. Выйти из Terminal.app

3. Перезагрузите машину.

4. Откройте терминал и повторите команду ssh.

У меня сработало (по крайней мере, так уже было).