SSH 鍵
設定 → セキュリティ → SSH 鍵。
なぜトークンの隣にこれがあるのか
Gitcito は 2 つの異なるものを認証しており、人がそれを 1 つだと思うのも無理はありま せん。
| 認証するもの | |
|---|---|
| ホストの API — リポジトリ、PR、イシュー、CI チェック | あなたの トークン |
https:// 経由の git 通信 |
URL に埋め込まれた、あなたのトークン |
git@… 経由の git 通信 |
あなたの SSH 鍵。システムの ssh 経由 |
git@github.com:me/api.git のようなリモートは、トークンに一切触れません。git は接続を
ssh に渡し、ssh はパーソナルアクセストークンなど聞いたこともありません。これは
例外的な話ではありません。同僚がリポジトリを用意した場合、.gitmodules が git@ の
URL を使っている場合、会社が HTTPS 認証を無効にしている場合、ホストが自社運用の
GitLab である場合 — いずれもこうなります。
そこで何かがおかしくなると、ssh は Permission denied (publickey) とだけ言います。
技術的には正しく、助言としては無価値です。
この画面が教えてくれること
~/.ssh で見つかった鍵ごとに、種類、サイズ、フィンガープリント、コメントが表示され、
さらに突然の失敗のほとんどを説明する 1 つの事実が付きます。
エージェントにある / エージェントにない。エージェントが保持していない鍵は何も 認証できませんし、OS に特別な指示をしていない限り、エージェントは再起動で中身を忘れ ます。「昨日は動いていた」の正体は、たいていこれです。
ここでできること
| アクション | 実行されるもの |
|---|---|
| 公開鍵をコピー | .pub の行をクリップボードに載せます。どのホストにも貼れる状態です |
| エージェントに追加 | ssh-add（macOS では --apple-use-keychain 付きなので、再起動しても残ります） |
| GitHub にアップロード | このプロファイルのトークンで POST /user/keys |
| 鍵を生成 | ssh-keygen -t ed25519。コメントには git のメールアドレスが入ります |
| 接続をテスト | ssh -T git@<host> を、文章に翻訳して表示 |
接続をテスト があるのは、ssh 自身の答えが誤解を招くからです。GitHub は認証には 成功し、そのうえで 失敗の終了コードを返します。シェルを提供しないためです。Gitcito は 終了コードではなくメッセージを読み、その読みを確かめられるよう生の出力を下に表示します。
制限を、はっきりと
- アップロードは GitHub だけです。 GitLab、Bitbucket、Azure DevOps には 公開鍵を コピー と、その鍵設定ページへの直接リンクが出ます。残る 3 つへの鍵の登録は実装されて おらず、ボタンもそのふりをしません。
- 生成が上書きすることはありません。
~/.sshにすでにある名前は拒否します。秘密鍵を 黙って上書きすることは、それを信頼しているすべてへのアクセスを失効させることであり、 どんな確認ダイアログもそれを取り返せるようにはしません。 - パスフレーズを Gitcito は保存しません。 生成時やエージェントへの追加時に入力した
ものは
ssh-keygen/ssh-addに渡され、そのまま捨てられます。再起動をまたいで 保持するのは、ssh-add経由の OS キーチェーンの仕事です。 ~/.ssh/configの編集はしません。 ホストの別名も、リポジトリごとの鍵の選択も ありません。それらはあなたの ssh 設定にあるものであり、Gitcito はそのファイルに 触れません。
マシンから出ていかないもの
Gitcito が秘密鍵を読むこと、表示すること、送信することは決してありません。 この画面が 並べるのは公開側とフィンガープリントです。どこかへ送られる唯一のものは、あなたが明示的に アップロード を押した公開鍵だけで、それもフィンガープリントを示す確認のあとに、 あなた自身のトークンで GitHub へ送られます。
関連項目: セキュリティと秘密情報 · ホスティングとプルリクエスト