テクノロジー · 実用ガイド
SSH の「Permission denied (publickey)」—別の鍵をコピーする前に提示フィンガープリントを証明する
有効な接続先と呼び出し元を固定し、実際に提示された公開鍵の指紋を対象アカウントへ対応付けます。そのうえで、権限やサーバーポリシーを変更する前に、拒否が起きた境界の証拠を確認します。
「Permission denied (publickey)」は、SSH 接続がユーザー認証まで到達したものの、要求したリモートアカウントで有効な公開鍵経路が受理されなかったことを示します。ただし、この一文だけでは、別名やユーザー名が違うのか、期待した鍵が提示されていないのか、提示済みの鍵がサーバー側で拒否されたのかまでは判定できません。
有効な接続先、実際に提示した指紋、対象アカウントの認可情報、サーバーの拒否証拠という4列の台帳を作ります。推測で鍵を追加したり認証設定を弱めたりせず、最初に対応が切れた境界だけを修正して、元の失敗文脈で再検証します。
接続先と呼び出し元を固定
失敗した command、alias、remote user、port、jump path、実行文脈をそのまま保存し、同じ宛先に対して ssh -G の有効設定を記録します。hostname と user だけでなく、IdentityFile、IdentitiesOnly、ProxyJump、設定ファイルの読み込み元も確認し、Terminal と IDE など別の呼び出し元を混同しないようにします。
ローカルのユーザー名や鍵ファイル名から remote account を推測してはいけません。公開鍵の認可はリモートアカウントに結び付くため、正しい鍵を持っていても user が違えば拒否されます。実効設定に出た対象を証拠台帳の最初の列として固定します。
実際に提示した鍵だけを記録
同じ接続先で ssh -vvv を実行し、認証区間に現れる各「Offering public key」の由来と指紋を順番どおりに記録します。設定に鍵が書かれていること、agent に鍵があること、鍵ファイルが存在することは、サーバーへ実際に提示された証拠とは別です。file missing と offered-but-rejected も異なる分岐です。
意図した指紋が提示一覧にない場合は、IdentityFile、agent socket、HOME、権限、実行ユーザーを確認します。必要なら -i と IdentitiesOnly=yes を付けた限定的なテストで、その鍵だけが提示されるか再確認します。このテストは診断用であり、恒久設定を変える前に元の呼び出し元との差分を記録します。
指紋を対象アカウントへ結合
公開鍵ファイルまたは承認済みの agent 一覧から ssh-keygen -lf を使って SHA256 指紋を取得します。秘密鍵の内容は表示・共有せず、指紋と公開鍵の由来だけを記録します。その指紋を remote account、Git ホスティングのアカウント、または管理された認可台帳に登録された鍵と正確に照合します。
指紋と対象アカウントの対応が不明なまま別の鍵をコピーすると、不要な認可だけが増え、IDE や service が引き続き別の鍵を提示する可能性があります。提示された指紋と対象アカウントの登録指紋が一致した事実を確認してから、サーバー側の調査へ進みます。
提示済み拒否の後だけ server へ移動
正しい指紋が実際に提示されたのに拒否された場合に限り、権限を持つ server 管理者が実際の認可元と同時刻の認証 log を確認します。対象 account、AuthorizedKeysFile、ownership、mode、certificate、Match 条件、許可 algorithm、外部の認可ディレクトリを順に照合し、別アカウントや別パスの証拠を混ぜません。
再帰的な chmod、所有者の一括変更、公開鍵認証の無効化やパスワード認証の安易な有効化は避けます。ログと実効設定で証明された account と path の要件だけを修正し、既存の正常な利用者や鍵まで巻き込まないよう変更範囲を限定します。
前後証拠で完了を確認
修正後は元の失敗文脈で ssh -G と ssh -vvv を繰り返し、接続先と user が同じであること、意図した SHA256 指紋が提示されたこと、認証方式を弱めずに成功したことを確認します。別の Terminal だけ成功した場合は完了とせず、失敗していた IDE、Git、service、container でも同じ境界を再検証します。
秘密情報を除いた証拠台帳、検証時刻、caller、変更した一項目、結果を保存します。次に agent、HOME、alias、設定管理が変わったときは、この前後差分を比較することで、鍵の再配布や広範な権限変更を繰り返さずに原因へ戻れます。
