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

なぜこれがいくつかのケースでうまくいくのか知っていますが、私が望むケースではわかりませんか？他の提案は大歓迎です！

ネクロクエション！このキーを使用して別のサーバーにログインできるという事実に基づいて、@ michael-hamptonは正しい道にあります。宛先サーバーにアクセスを拒否している何か（ファイアウォール/ tcpラッパー/ sshd構成）があります。誤ったキー形式に関するこのすべての話は、デバッグ情報の誤った解釈に基づくレッドニシンです。この線

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

sshがキーを理解できたことを示します。

SSHキーが間違った形式で保存されています。OpenSSHは、1行に配置されるキーを使用します。あなたは必要ssh-keygenと-iし、-mオプションを参照してくださいman ssh-keygen。おそらくこれらの1つ：

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

出力を新しいキーファイルとして使用します（ssh-keygen ... >newkeyfile）。

編集1：

「このオプションでは、暗号化されていない秘密（または公開）鍵ファイルが読み取られます」

したがって、おそらくファイルは、その形式を理解するプログラムによって、パスフレーズなしのファイルに変更する必要があります。

まず、sshdログを確認する必要があります。すなわち

less /var/log/secure

UNIXの配布ファイルによっては、セキュリティログが異なる場合があります。しかし、もしそうなら、ログインできない理由を教えてくれるはずです。

私も最近この問題に直面しました。私の場合、.ssh、rsaファイル、ホームディレクトリ、およびユーザーに関連するすべてのものを含め、すべての権限が適切でした。問題は、以前に生成した公開鍵が.sshにあり、ログインに使用していた秘密鍵に対応していないことでした。.sshから公開鍵を削除すると、問題が修正されました。

私はssh-keygenを使用して.sshディレクトリを作成していましたが、このpubキーが原因で問題が発生しました。

ここでの答えはあまり明確ではないようです。マークワグナーの答えはそれをカバーしていますが、状況を完全に説明していません。

出力の行には、デバッグレベルが前に付いています。これは、それらの重要性にもヒントを与えます。ただし、数値が小さいほど重要です。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としてas type 0およびid_rsaas が識別されています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 identityなので、プロトコル1のRSAキー入力は、キー交換中に無視されます。

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が見つけたキーを解析するために複数の方法を試行したことによる赤ニシンであり、キーに関する実際の問題ではありません。

MacOS 10.7.5を搭載したMacBook Proでも同じ問題が発生しました。私の鍵には何の問題もありませんでした。それは、それらが暗号化されていて（本来のパスフレーズで）、sshによって正しく暗号化解除されていないということです。そのようでssh-agent問題を抱えています。

この記事によると、これを試してください：

1. 置く/usr/bin/ssh-agentあなたのログイン項目に（ - > [ユーザーとグループ-システム環境設定>を選択し、ユーザ- >ログイン項目）。/usr/binダイアログボックス内に移動するのは非常に難しいため、この記事では、ホームディレクトリ（ln -s /usr/bin/ssh-agent）にリンクを作成することを推奨しています。このリンクは、ログインアイテムに配置したら削除できます。

2. Terminal.appを終了します

3. マシンを再起動します。

4. ターミナルを開き、sshコマンドを再試行します。

私のために働きました（少なくとも、一度はありました）。