いつものようにssh-keygenして、またはしないで
なじみのGitリポジトリ管理ツール（ここではGitLab）で任意のリポジトリをgit cloneしようとしたときのこと…
起こったこと
高スペックPCを手に入れたのでGitやらエディタやら初期設定中。
「プロジェクトのソースコード、ローカルに落とすかー」
$git clone ssh://*****
するとエラーでcloneできなかった。。。
エラーメッセージには親の顔より見たお馴染みの文面が。
$Error:Permission denied（PublicKey）
こういうとき、皆さんもいろんな観点で何が問題かを特定しに行くと思いますが
自分の経験上、今までは以下のような対策をとっていた。
- keygenしたssh鍵に権限付与し忘れor付与したけど戻ってしまっている
- よくやるやつ。
- configファイルに半角スペース等のごみ混入
- コピペミスとか手書きで修正した箇所にスペルミスとか
秘密鍵の指定場所を間違えてないかチェック - このPCにSSHクライアントがインストールされてない説
- そんなことある？はまるとこういうところも一応チェックしがち
- プロキシ
- ネットワーク不良でgitサーバにアクセスで来てない
- 全然違う公開鍵をGitサーバに登録している
…うーん、全部大丈夫そう。。。
検証
プロジェクトのソースコードだけcloneできないのか、
社内GitLabの適当なリポジトリをcloneしてみた。
- GitLabの任意のプロジェクトを試しにclone
- SSH接続：clone不可。
HTTP接続：いけた！
原因とその発覚経緯
$ssh -T -v user.name@host
でログ出しながらgerritサーバとのssh接続確認してた。
相変わらずPermission Denied(PublicKey)。
ばーっと出てきたログを見ていると、以下のような記載を発見。
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ssh-ed25519
ssh-keygenを-tオプションを付けずに鍵生成すると、
デフォルトで暗号化方式はrsa方式が採用される。
私はこの時、楕円曲線暗号方式がセキュリティ最強ということで
意図的に暗号方式をed25519に変更してkey-genしていた。
上記ログより、
-
Gitサーバ側はecdh-sha2-nistp256暗号化方式をアルゴリズムとして採用している
-
ホスト側（クライアント。つまり自分）はed25519でkey-genしていた
-
公開鍵にはいろいろ種類がある。（RSAとかECDSAとか）それぞれは暗号化方式が異なる。
-
ふむ、この記事がわかりやすい。アルゴリズムが合わないと複合できないもんね。
なんとなくわかってきた。
解決策
-
ssh-keygenをもう一度やろう！（最強鍵はサーバのアルゴリズム設定とウマが合わなかったらしい…）
サーバ側の
ecdh-sha2-nistp256に合わせてkey-genしよう。
…ecdhでkeygenする方法、ググってもなかなか出てこない。。。調査していると、ecdhというのは楕円曲線鍵共有方式の一つであるらしい（Wikipedia参照）。
…なら、同じ楕円曲線鍵共有方式のecdsaでkeygenすればできたりしないかな？
$ssh-keygen -t ecdsa
んで、あとはお馴染みの、ミスりやすいとこに注意して…
- 生成した鍵どっちもに権限つける（忘れがち、、、）
- configファイルに書いてある秘密鍵の名前書き換える（id_ecdsaとかid_ecdsa.pubとかになって生成される）
- サーバに新しく生成した公開鍵を登録する
よっしゃ、cloneできた！！！
余談
使用しているGitサーバの暗号化方式がちょっと古かったみたいです。
さいきょー鍵が一般普及しているものとしんじきっていたことが今回のハマりポイントでした。
参照記事：
https://pan-shoku.com/ed25519-github/
https://www.ibm.com/docs/ja/datapower-gateway/2018.4?topic=commands-kex-alg
https://qiita.com/angel_p_57/items/2e3f3f8661de32a0d432
https://qiita.com/ntrv/items/ed0c14f3ea7ee20fe6f9
大変参考になりました…
問題解決には先輩のK氏に助けてもらいました。いつも感謝です