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

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, который привел к этому ключу pub и, следовательно, к проблеме.

У меня была такая же проблема на моем 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.

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