SSH運用をしっかり把握する

はじめに

サーバー接続の時、SSHを使っている現場は多いと思います。

「管理者から鍵ファイルをもらって、~/.ssh/に置いて、接続する」

この流れ、なんとなくでやっていませんか？

実はこれ、本来の運用とは異なっています。
とはいえ、実際に、この運用がされている現場も多いと思うので、本来の運用、実際に現場でよくある運用を整理してみます。

本来の運用

SSH鍵認証の正しい流れはこうです。

1. ローカルPCで秘密鍵・公開鍵のペアを生成する
2. 公開鍵だけをサーバー管理者に渡す
3. 管理者がサーバーの authorized_keys に公開鍵を登録する
4. 接続時は、手元の秘密鍵で認証される

ポイントは「秘密鍵は自分のPCから一切出ない」ということ。

GitHubやGitLabにSSH接続する際の設定手順を思い出してください。自分で鍵を生成して、公開鍵をWebの設定画面に貼り付けましたよね。あれがまさに正しい運用です。

# 鍵ペアの生成
ssh-keygen -t ed25519 -C "[e-mail]"

# 公開鍵の内容を確認して、管理者に渡す
cat ~/.ssh/id_ed25519.pub

実際に取られがちな運用

ところが、現場ではこんな運用をよく見かけます。

• Slackで .pem ファイルが送られてくる
• 社内Wikiに鍵ファイルが置いてある
• 「この鍵を ~/.ssh/ に置いて使ってね」で済まされる
• 何なら複数人で同じ鍵を共有している

つまり、管理者が秘密鍵を生成して配布するという、本来とは逆の流れになっています。
あれ、公開鍵をサーバーに置かないとダメなんじゃなかったっけ？どっちだったっけ？てか、鍵作るのって誰だっけ？みたいな感じでカオスになります。

なぜこの運用が広まっているのか

この運用方法が広まっている理由を推測してみます。

管理が楽

各メンバーに公開鍵を提出してもらい、一人ひとり authorized_keys に追加していくのは手間がかかります。

秘密鍵を配布する方式なら、サーバー担当者のボールだけで作業が完結します。鍵を渡したら終わり。相手からのアクションを待つ必要がありません。

教育コストの省略

「公開鍵を生成して送ってください」と言っても、接続する開発者がその手順を知らないことがあります。

説明する手間を考えると、「この鍵使って」で済ませたくなる気持ちはわかります。

「動いてるからいい」文化

セキュリティ的に正しくなくても、接続できていれば業務は回ります。

問題が起きていない以上、わざわざ運用を変える動機が生まれにくいです。

最初の現場がその運用だと疑問を持たない

新人エンジニアが最初に経験した現場がこの運用だった場合、それが標準だと思い込みます。

周りも同じやり方をしていて、誰も疑問を呈さない。

問題点

「動いてるならいいじゃん」と思うかもしれませんが、いくつか深刻な問題があります。

退職者の鍵を無効化できない

同じ秘密鍵を複数人で共有していた場合、誰かが退職しても鍵を無効化できません。無効化するには鍵自体を作り直して、全員に再配布する必要があります。

実際には面倒なのでそのまま放置され、退職者がサーバーにアクセスできる状態が続くことになります。
PC上にしかなければ、PCを返却すれば済みますが、PC外に鍵を保存している可能性は0ではないです。

漏洩時の影響範囲が大きい

誰か一人のPCから秘密鍵が漏洩した場合、同じ鍵を使っている全員に影響が及びます。

各自が自分の鍵を持っていれば、漏洩の影響は当事者だけに限定できます。

誰がアクセスしたか追跡できない

全員が同じ鍵を使っていると、サーバーのログを見ても誰がアクセスしたのか区別できません。

監査やインシデント対応の際に「誰が何をしたか」を追跡できないのは、大きなリスクです。

秘密鍵の受け渡し自体がリスク

Slackやメールで秘密鍵を送る行為自体が、漏洩のリスクを生んでいます。

まとめ

現場ごとに色々な運用方法がありますが、

• 秘密鍵は自分で生成して、自分のPCから出さない
• 公開鍵だけをサーバー（やサービス）に登録する

本来、セキュリティ上の理由からこれらの運用が正しい運用になります。

現場で「秘密鍵をもらう」運用に遭遇したら、それは本来の形ではないと認識しておく必要があります。

すぐに運用を変えられなくても、正しい形を知っているだけで、いつか改善を提案できる立場になったときに役立つはずです。