web-dev-qa-db-ja.com

このsshエラーはどういう意味ですか？

これが私の最後の手段であります。私は何時間もここで問題を理解しようとしました。

取引は次のとおりです。秘密鍵をマシン＃1からマシン＃2にコピーしました。マシン＃1はsshを介して公開鍵でサーバーに接続できますが、マシン＃2はサーバーに接続しようとすると次の出力を提供します。

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa [email protected] -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).

明らかに私が省略したより多くのデバッグ出力があり、私は要求に応じて提供できます。しかし、私は秘密鍵ファイルを好きではないと確信しています。

また、それをマシン＃1からマシン＃2にどのようにコピーしたかに関係しているのではないかと疑っていました。テキストを秘密キーからフラッシュドライブにコピー/貼り付けました。これは問題になる可能性がありますが、この方法を別の有効な秘密鍵ファイルに複製し、元のコピーと貼り付けたファイルとの差分をとった場合、それらは同一です。

私はこれに苦労してきました。なぜ私のキーが気に入らないのかについてもう少し情報を得ることができれば、私はそれを修正できると確信しています。誰かこれについて何かアイデアはありますか？ファイルが実際にはRSAキーであることをsshに伝えるメタデータがどこかにありますか？

sshrsaprivate-keykeys
9
kevin

私の経験では、2つの最も一般的なキーベースの認証エラーは

  1. $HOME/.sshディレクトリに対する不適切な広範な権限
  2. 公開鍵をリモートシステムにコピーする際のエラー

ファイルのアクセス許可

OpenSSHは、あなたを自分から守るために多くのことを行います。これが発生する最もユーザーに影響を与える方法は、ローカルのsshフォルダーにアクセスできるユーザーに厳しい制限を適用することです。あなたは本当にあなただけ、そしてあなただけがディレクトリにアクセスすることを望んでいます。まあ、uid = 0の人なら誰でも、それを回避する良い方法はありません。だからあなたがする必要があるのは単にあなたの許可を変更することです：chmod -R go-rwx ~/.sshこれは所有者を除くすべてのユーザーから.sshディレクトリの下のすべてのファイルへの読み取り、書き込み、実行権限を削除します--あなた =。

承認済みキーの問題

公開鍵を含むファイル（通常は$HOME/.ssh/authorized_keys）は、SSHが秘密鍵を受け入れる方法を理解するための非常に具体的な形式に適合している必要があります。各キーは、少なくとも2つのフィールドで構成される必要があります

  1. 使用される鍵のタイプ（RSA、DSA、RSA1など）
  2. キー

このファイルでは、各キーとそのすべてのオプションおよびコンポーネントパーツを1行に1つずつリストする必要があります。キーは非常に長くなる傾向があるため、端末では折り返されて2行として表示されることがよくあります。これにより、コピー/貼り付けを試行するときに混乱が生じることがあります。これは、画面上のキーが折り返される場所に1つ以上の改行が挿入される場合があるためです。この問題の修正canシェル初心者には少し注意が必要です。

実行してみてください
wc -l ~/.ssh/authorized_keys
これにより、ファイルの行数が出力されます。その数を、ファイルにあると予想されるキーの数と比較します。この1つのキーのみを受け入れる場合は、公開キーファイルのコピーを作成することもできます。これは、承認されたキーファイルと同じ形式であるためです。何かのようなもの
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
または、同じシステムに公開鍵がある場合は、
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

さらに、リモートホストのログファイルを調べて、そこにエラーが報告されていないかどうかを確認します。ほとんどの場合、ファイルは/var/log/secure.logまたは/var/log/authです。

7
Scott Pack

ただし、サーバーに接続するには、マシン2の新しいキーペアを生成する必要があります。多くの場合、公開鍵には、それらを生成したユーザーとマシン名がリストされます。これは、サーバー上のauthorized_keysファイルで明らかになるはずです。

0
Dru

指定したデバッグメッセージは、秘密鍵ファイルが実際には公開鍵/許可されたホストファイルであると想定して読み取られることを意味します。これは致命的なエラーではない可能性があります（接続が機能している場合でも、このようなメッセージが表示されます）。 「申し出」や「お送りしました」などと言っていませんか？

0
Ansgar Esztermann