ホストは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上のPuTTYでホストに接続でき、別の秘密キーを使用して電話に接続できます。
何か考えはありますか？
/ 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つを見て、すべてを正しく行ったかどうかを確認してください。 ここ は1つです。だから私はそれを再び繰り返すつもりはありません。
非常に基本的な概念は（ here からコピー）です。
鍵ベースの認証では、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).については、確認することがいくつかあります。- ユーザー名が間違っています
- 間違ったキーペア
ターゲットホストが間違っています
次の部分は少し混乱しています：
_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 で説明されているように、段階的に認証プロセスを実行してみましょう。
- クライアントはまず、認証したい鍵ペアのIDをサーバーに送信します。
- サーバーチェックは、クライアントがキーIDでログインしようとしているアカウントのauthorized_keysファイルです。
- ファイル内でIDが一致する公開鍵が見つかった場合、サーバーは乱数を生成し、公開鍵を使用して番号を暗号化します。
- サーバーはクライアントにこの暗号化されたメッセージを送信します。
- クライアントが実際に関連付けられた秘密鍵を持っている場合、その鍵を使用してメッセージを復号化し、元の番号を明らかにすることができます。
- クライアントは、復号化された番号と、通信の暗号化に使用されている共有セッションキーを組み合わせ、この値のMD5ハッシュを計算します。
- 次に、クライアントはこのMD5ハッシュを暗号化された番号メッセージへの応答としてサーバーに送り返します。
- サーバーは、クライアントに送信した同じ共有セッションキーと元の番号を使用して、MD5値を独自に計算します。それはそれ自身の計算をクライアントが送り返したものと比較します。これら2つの値が一致する場合、クライアントが秘密鍵を所有しており、クライアントが認証されていることを証明します。
あなたの場合、ご覧のとおり、リモートコンピューターは_public key_のみを受け入れ、そのキーでパケットを暗号化して、クライアントコンピューターに送り返しました。次に、クライアントコンピューターは、_private key_が正しいことを証明する必要があります。適切なprivate_keyのみを使用して、受信したメッセージを復号化し、応答を返すことができます。この場合、クライアントはその処理に失敗し、認証プロセスは成功せずに終了します。
これが問題の理解と解決に役立つことを願っています。
あなたの問題はかなり一般的であり、私が言ったことも明らかであるようです。
Permission denied (publickey).
それはあなたにとって何か意味がありますか？私にとってそれは私にとって多くのことを意味します。
強制モードplsでselinux runninがあるかどうかをサーバー側で確認できますか？そうでない場合は、selinuxの実行モードを教えてください。
また、もう一度試行してその試行の監査ログをキャプチャし、ここに投稿できると、その理由が明確になります。
tail -f /var/log/audit/audit.log (and try to attempt)
明確であるがファイル許可ではない許可問題です:-)
Sshファイルに対する権限は正しいですか？
.sshフォルダー-> 700
公開鍵-> 644
秘密鍵-> 600
ユーザーとグループも確認してください
あなたはあなたがWindowsマシンで同じキーを持っていると言います。 Linuxマシンにある秘密鍵ファイルが正しいことを確認しますか？秘密鍵は、sshが簡単に理解できないPuTTY形式である可能性があります。いずれにせよ、私が間違ったまたは無効な秘密鍵ファイルを置いた場合、私はあなたが持っているのとまったく同じエラーを受け取ります。
この問題を修正するには、別のマシンのキーを再利用するのではなく、Linuxマシンで新しいキーを生成する方が適切です。新しい公開鍵をホスト上のauthorized_keysファイルに追加するだけで、WindowsのWindows鍵とFedoraの新しいLinux鍵の両方を使用できます。
問題（私の場合は...）はキーのタイプが原因であるようです。
ローカル~/.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 [〜＃〜] RSAキーは、$HOME/.ssh/id_rsaにあるものとは異なり、リモートサーバーで問題なく受け入れられました。
その後、ssh-addを取得するために、冗長な$HOME/.ssh/id_rsaであるはずのことを実行することになりました。それを行った後、ssh-add -lに同じキーのtwoエントリが含まれていることに気付きました。
% 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キーを受け入れないという問題がある場合でも、authconfigを使用して/etc/pam.d/ディレクトリを再構築することは、解決。
ユーザーのホームディレクトリの権限を確認してください。それは重要です。 755でなければなりません。700または770は機能しません。
ssh_configで、Cipher、Ciphers、またはMACs行のコメントを外したり、追加/削除/追加したりしてみてください。
sshdは、リクエストに含まれていないある種の特定の暗号を探しているようです。これは、ssh_configで設定することで追加できます。
...そして、リモートサーバーでPubkeyAuthenticationがnoに設定されていないことを前提としています。これは間違いなく失敗するためです。