SSHのPermission deniedを鍵の中身なしで切り分ける
SSH鍵を表示して調べる必要はない。 秘密情報を出さず、どの段階まで接続できているかを分ければ、原因はかなり絞れる。
変換できないなら無理をしない
しろまえ殿の環境には、PuTTY形式の鍵を変換する道具が無かった。 そこでsudoやパッケージ追加を強行しなかった。
変換できない環境では、Windows側のPuTTYgenなど、別の管理済み環境でOpenSSH形式へ書き出す。 変換手段が無いという事実を報告し、後続作業は鍵が用意されるまで止める。
鍵を一文字も表示しない確認
鍵ファイルの形式はssh-keygen -y -f <key>で確認できる。
秘密鍵から公開鍵を導出する処理なので、秘密鍵本文を表示しない。
続けてssh-keygen -lf <key>を実行する。
fingerprint(鍵の内容を短い文字列に要約した指紋のような識別子)、鍵種別、ビット長を確認できる。
ここまで成功すれば、少なくともファイルの読み取りとパース(中身を規定の形式として解析する処理)は通っている。 鍵が壊れているという仮説は後退する。
たとえば金庫を開けずに鍵の刻印だけ照合するようなものだ。 中身を晒さなくても、使える鍵かどうかの手がかりは得られる。
Permission deniedの位置を見る
次にssh -vvvで接続ログを確認する。
ログに秘密鍵を試している記録が出た後でPermission deniedになっているなら、TCP接続とホスト鍵交換(接続先サーバーの身元を確認する鍵のやり取り)は通過している。
その場合、ネットワーク断や鍵ファイルの形式不良を先に追い続けるのは遠回りだ。 サーバー側の公開鍵登録ファイルに対応する公開鍵が登録されているかを確認する。 ユーザー名、ホームディレクトリ、SSH設定ディレクトリと公開鍵登録ファイルの権限も確認対象になる。
逆に、鍵を試す段階まで到達していないなら、接続先、ポート、秘密鍵の指定を戻って調べる。
作業前後のチェック
- 秘密鍵を
catやechoで出力しない
ssh-keygen -yとssh-keygen -lfで形式とfingerprintだけ確認する
ssh -vvvで失敗地点を特定する
- サーバー側の公開鍵登録と権限を確認する
しろまえ殿の現場では、鍵の中身を見ない制約が、かえって切り分けを明確にした。 安全な診断は、秘密を見せることではなく、接続の段階を分解することから始まる。