ホストはSSHキーを受け入れましたが、クライアントは切断されました

Helo、

fedora 23のインストール後、SSHに問題があります。

プライベートキーでリモートホストに接続したくない場合、ホストはキーを見つけます。

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

しかし、あなたが見るように、私のクライアントはそれ自体で切断します

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

私は同じ秘密鍵を使用してWindowsのパテでホストに接続でき、別の秘密鍵を使用して電話に接続できます。

何か考えはありますか？

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

ありがとうございました

編集：パスワードで接続できます

まず第一に、公開鍵ベースの認証をセットアップまたは構成する方法に関する非常によく書かれた詳細なドキュメントがオンラインで入手できます。それらの1つを見て、すべてを正しく行ったかどうかを確認してください。こちらです。だから私はそれを再び繰り返すつもりはありません。

非常に基本的な概念は（ここからコピー）です。

キーベースの認証では、2つのキーを使用します。1つは誰でも見ることができる「公開」キー、もう1つは所有者だけが見ることができる「秘密」キーです。鍵ベースの認証を使用して安全に通信するには、鍵ペアを作成し、秘密鍵をログインしたいコンピューターに安全に保管し、公開鍵をログインしたいコンピューターに保管する必要があります。

今あなたが投稿したデバッグログから：

• 2人の異なるユーザーが関与しているようです。/home/theo/.ssh/authorized_keysと/home/tbouge/.ssh/id_rsa。あるユーザーとして別のユーザーのホームディレクトリにログインしようとしていますか？
• エラーPostponed publickey for theo..は、公開鍵方式の前に不要な認証方式が試行されたことを意味します。SSHは、configで有効になっているすべての認証方法を次々に試行します。あなたのケースでは、GSSAPIAuthentication yes使用していないものを有効にしました。あなたは安全にそれを無効にすることができGSSAPIAuthentication noます。
• debug2: we did not send a packet, disable methodほとんどの場合、秘密鍵ファイルを処理できない（ファイルのアクセス権または名前の問題のいずれか）。 SSHは、ローカルコンピューターとリモートコンピューターの両方のディレクトリとファイルのアクセス許可に非常に敏感です。（chown user_name:user_group -R /home/user、chmod 700 /home/.ssh、chmod 600 /home/.ssh/authorized_keys）。したがって、あなたが正しく設定されていることを確認してください。これを参照してください：https : //unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server

• 3番目のエラー：Permission denied (public key).については、確認することがいくつかあります。

  • ユーザー名が間違っています
  • 間違ったキーペア

  • 間違ったターゲットホスト

    • 詳細は次のとおりです：https : //stackoverflow.com/questions/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance。

次の部分は少し混乱しています。

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

それをよりよく理解するために、ここdigitaloceanで説明されているように、認証プロセスを段階的に見ていきましょう：

1. クライアントはまず、認証したい鍵ペアのIDをサーバーに送信します。
2. サーバーチェックは、クライアントがキーIDでログインしようとしているアカウントのauthorized_keysファイルです。
3. ファイル内でIDが一致する公開鍵が見つかった場合、サーバーは乱数を生成し、公開鍵を使用して番号を暗号化します。
4. サーバーはこの暗号化されたメッセージをクライアントに送信します。
5. クライアントが実際に関連付けられた秘密鍵を持っている場合、その鍵を使用してメッセージを復号化し、元の番号を明らかにすることができます。
6. クライアントは、復号化された番号と、通信の暗号化に使用されている共有セッションキーを組み合わせ、この値のMD5ハッシュを計算します。
7. 次に、クライアントはこのMD5ハッシュを暗号化された番号メッセージへの応答としてサーバーに送り返します。
8. サーバーは、クライアントに送信した同じ共有セッションキーと元の番号を使用して、MD5値を独自に計算します。それはそれ自身の計算をクライアントが送り返したものと比較します。これら2つの値が一致する場合、クライアントが秘密鍵を所有しており、クライアントが認証されていることを証明します。

あなたのケースでは、ご覧のように、リモートコンピューターはを受け入れ、public keyそのキーでパケットを暗号化してクライアントコンピューターに送り返しました。次に、クライアントコンピュータは、適切であることを証明する必要がありますprivate key。適切なprivate_keyのみを使用して、受信したメッセージを復号化し、応答を返すことができます。この場合、クライアントはそれを行うことに失敗し、認証プロセスは成功せずに終了します。

これが問題の理解と解決に役立つことを願っています。

sshファイルに対する権限は正しいですか？

.sshフォルダー-> 700

公開鍵-> 644

秘密鍵-> 600

ユーザーとグループも確認してください

あなたはWindowsマシンで同じキーを持っていると言います。Linuxマシンにある秘密鍵ファイルが正しいことを確認しますか？秘密鍵は、sshが簡単に理解できないパテ形式である可能性があります。いずれにせよ、私が間違ったまたは無効な秘密鍵ファイルを置いた場合、私はあなたが持っているのとまったく同じエラーを受け取ります。

この問題を修正するには、別のマシンのキーを再利用するのではなく、Linuxマシンで新しいキーを生成する方が適切です。新しい公開鍵をホストのauthorized_keysファイルに追加するだけで、WindowsのWindows鍵とFedoraの新しいLinux鍵の両方を使用できます。

あなたの問題はかなり一般的であり、私が言ったことも明らかであるようです。

 Permission denied (publickey).

それはあなたにとって何か意味がありますか？私にとってそれは私にとって多くのことを意味します。

強制モードplsでselinux runninがあるかどうかをサーバー側で確認できますか？そうでない場合は、selinuxの実行モードを教えてください。

また、もう一度試行してその試行の監査ログをキャプチャし、ここに投稿できると、その理由が明確になります。

  tail -f /var/log/audit/audit.log  (and try to attempt)

明確であるがファイル許可ではない許可問題です:-)

問題（私の場合は...）はキーのタイプが原因であるようです。

ローカル~/.ssh/configファイル（Fedora 23クライアントマシン）に以下を追加することで解決しました：

PubkeyAcceptedKeyTypes=+ssh-dss

サーバーとクライアントの両方の構成ファイルにその行を追加しましたが、違いはクライアント側だけです。600設定ファイルを読み取るための権限が必要であることに注意してください。

他の誰かがまだこの問題を抱えているかどうかはわかりませんが、問題が発生していた1台のマシン（ラップトップ）についてようやく解決しました。私は最終的に何がそれを整理したか知っていると思います、そしてそれがまだこれに遭遇しているかもしれない他の誰かを助けることを願って、そして誰かがうまくいけば私の解決策をチェックしてそれが実際に何であるかを確認できるように、ここに情報を残します問題を解決しました。

結局のところ、問題は（私にとっては）SSHではなく、PAMがキーを構成する方法にありました。の構成/etc/pam.dは古くなっており（Fedora 22で正常に機能していました）、その結果、ログイン時に正しいキーが取得されず、[キー]を取得できません$HOME/.ssh/でした。このコマンドを実行する：

# sudo authconfig --updateall

/etc/pam.d構成を適切に再構築しました。次回の再起動時に、ログインして初めてサーバーにsshでログインしようとしたときに、ダイアログボックスでsshキーのパスフレーズを入力するように求められました（$HOME/.ssh/id_rsa）。私はそうしました、「ログイン時に自動的にロックを解除する」ボックスをチェックして、出来上がりです！ラップトップからsshを実行する私の能力が復元されました。

バックグラウンド

これを解決するための手掛かりは、外部ソースからRSAキーをインポートしたときです。（USBキーは、私は私のホームネットワークのための私の「リモートアクセス」キーで、持ち歩く。私が侵入した後、前に私の外向きのサーバー年にPasswordAuthオフ。）後ssh-add-ing THATに座っ1とは異なり、RSAキーを$HOME/.ssh/id_rsa、問題なくリモートサーバーに受け入れられました。

それから私はssh-add拾うために冗長であるはずだったものをやることになりました$HOME/.ssh/id_rsa。私はそれを実行した後、同じキーの2つのエントリがssh-add -l含まれていることに気付きました。

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

2つのエントリの1つにキー識別子が表示されず、公開署名と一致する秘密キーのファイル名だけが表示されていることに注意してください。まるで、秘密鍵が鍵リング・マネージャーによって本当にアンロックされなかったかのように。

私はそれがまさに起こっていたと信じており、PAMはパスフレーズでロック解除されていなかったSSHエージェントに「不正なキー」を渡していました。そのため、sshが鍵で認証しようとしたときに、実際には鍵のペアの（ロック解除された）秘密の半分を持っていなかったため、認証は失敗しました。

その最後のビットは推測ですが、F23にアップグレードした後にリモートホスト（以前は使用されていた場所）がsshキーを受け入れないという問題が発生しているかどうかに関係なく、ソリューション/etc/pam.d/を使用してディレクトリを再構築することauthconfigは価値があります。

ユーザーのホームディレクトリの権限を確認してください。それは重要です。755でなければなりません。700または770は機能しません。

あなたにはssh_config、コメント解除および/またはいずれかへの追加/削除/追加してみてくださいCipher、CiphersまたはMACsライン（複数可）。

その私には見えるsshdあなたにそれを構成することで追加することができます要求に含まれていないいくつかの並べ替え、特定の暗号を探していますssh_config。

...そして、リモートサーバーでがPubkeyAuthentication設定さnoれていないことを前提としています。これは間違いなく失敗するためです。