とある検証のため、SSHできる環境が欲しくなった。
ということで、Dockerを使ってお手軽にSSHサーバーを建てていく。

やること:

1. SSHするためのサーバーをDockerコンテナで作る
2. ssh-agentのキャッシュによる罠について検証する

1. サーバーを立てる

SSHするためのサーバーをDockerコンテナで作る。

方針

• linuxserver/openssh-serverというDockerイメージを使用
• パスワード認証は使わず、公開鍵認証のみを使う
• ユーザーnanasiでlocalhost:22にあるサーバーに接続する

linuxserver/openssh-serverとは？

簡単にSSHサーバーが建てられるDockerイメージ。
コンテナを起動する=SSHサーバーを起動する、というお手軽仕様。

ちなみに独自仕様もりもり（たぶん）。
設定は設定ファイルじゃなくて環境変数でやろう。

Openssh-server⁠ is a sandboxed environment that allows ssh access without giving keys to the entire server. Giving ssh access via private key often means giving full access to the server. This container creates a limited and sandboxed environment that others can ssh into. The users only have access to the folders mapped and the processes running inside this container.

やり方

コンテナを起動する

まずはコンテナを起動するためのコマンドを書く。
ターミナルで片付けると辛いので、それ用のファイルを作ったほうがいい。

例えばこんな感じ。

docker run -d \
  -p 22:2222 \ # ホストのポート:2222
  -e PUBLIC_KEY="後で公開鍵を入れる" \
  -e LOG_STDOUT=true \
  -e USER_NAME=nanasi \
  linuxserver/openssh-server

なお、このファイルはどこに置いてもいい。
というかどこのディレクトリで作業しても同じだと思う。

接続について

ここで一度現状確認。

• 使用している秘密鍵: ~/.ssh/id_ed25519
  • 今回はsshコマンドに-iを使用していない
  • そのため~/.ssh内にある鍵がデフォルトで使われる
• 接続があるとサーバーは標準出力にログを吐く
  • ここからどのアルゴリズムの鍵で接続されたかがわかる
  • 今回ならED25519と出力される
• 22番=SSHのデフォルトのポートにサーバーがあるため、ポートを指定しなくても接続できる
• ~/.ssh/known_hostsにはlocalhostのことが書かれている
  • コンテナを起動し直すとホスト鍵が変わってしまうため、公開鍵だかフィンガープリントが一致しなくなりエラーが出る
  • 対策: コンテナを起動するたびにknown_hostsを削除する
• ちなみに使用OSはMac

2. ssh-agentについて検証する

SSH接続ができる環境が整ったということで、さっそく検証。
内容はざっくり言うと、意図せずにssh-agentの秘密鍵で接続されること。

概要

• ssh-agentは鍵をキャッシュする
• MacOSではキーチェーンに鍵を追加できる=半永久的に鍵が保管される
  • 実際に使うには別で.bashrcなどでssh-addする必要あり
  • 検証では鍵が使える状態になっている想定
• キーチェーンの鍵は~/.sshを消しても残る
• sshの-iオプションでは秘密鍵を指定できる
  • 指定されなかった場合は~/.sshにある（デフォルト名の？）鍵で接続される
  • -iとssh-agentならssh-agentが優先

=> ~/.ssh/id_ed25519で接続してるつもりなのに、ssh-agentのRSA鍵で接続してる!?
...ということが起こりうるのでは？

検証手順

大きく3ステップに分かれている

1. RSA鍵を追加:

   1. RSA鍵（Rとする）を用意し、ssh-agentを通してキーチェーンに追加する
   2. SSHサーバーに公開鍵R'を追加する
   3. ssh-add --apple-use-keychainでssh-agentに秘密鍵Rを追加する
   4. 秘密鍵Rで接続を試み、成功する

2. RSA秘密鍵を削除:

   1. 鍵ペアRを~/.sshフォルダごと削除する
   2. ED25519鍵（E）を用意する
   3. SSHサーバーに公開鍵E'を追加する
   4. 接続を試みたとき、使われるのは秘密鍵R or E？<= 検証1

3. RSA公開鍵を削除:

   1. 別のED25519鍵（E2）を用意する
   2. SSHサーバーから公開鍵R'を削除する
   3. SSHサーバーに公開鍵E2'を追加する（置き換える形）
   4. 接続を試みたとき、使われるのは秘密鍵R or E2？ <= 検証2

公開鍵ファイル

検証には公開鍵を複数登録する必要があるので、PUBLIC_KEYではなくちゃんとしたファイルで管理したい。
そんなときは、ボリューム + PUBLIC_KEY_FILEを組み合わせる。

rm ~/.ssh/known_hosts
docker run -d -p 22:2222 \
  -e PUBLIC_KEY_FILE="/config/user/authorized_keys" \
  -e LOG_STDOUT=true \
  -e USER_NAME=nanasi \
  -v config:/config/user \ # 既存のファイルは消えないので安心
  linuxserver/openssh-server

# これは公開鍵を入れるファイル

1. RSA鍵を追加

これは通常のSSH接続。
ただし、キーチェーンに鍵を追加する点に注意。

1. ssh-keygen -t rsaで鍵ペアRを生成する
2. ./config/authorized_keysに公開鍵R'を追加する
3. ssh-add --apple-use-keychainでssh-agentに秘密鍵Rを追加する
4. ssh nanasi@localhostで接続を試みる => 成功

2. 別のED25519鍵を追加

ここでは秘密鍵Rを削除し、それでもキーチェーンの鍵は有効か？を調べる。
結論から言うと有効なので、~/.sshを消しただけだと鍵は完全に消せていないことになる。

1. rm -r ~/.sshで秘密鍵Rを削除する
2. ssh-keygen -t ed25519で鍵ペアEを生成する
3. ./config/authorized_keysに公開鍵E'を追加する
   • 公開鍵R'はそのまま
   • 各公開鍵の区切りは改行にする
4. SSHサーバーのコンテナを作り直す
5. ssh nanasi@localhostで接続を試みる => 秘密鍵Rが使われている

公開鍵R'を削除

サーバーから公開鍵R'を削除する。
かつ、あまり意味はないだろうが、新しいED25519鍵（E2）の再生成もする。

このときssh-agentの秘密鍵Rは使えなくなる。
では代わりに手元の使用可能である秘密鍵E2が使われるのか？ = フォールバックはあるか？が今回の検証内容。

結論

結論から言うとフォールバックされる。
しかもデバッグモード（-v）ではない場合、特にそれを示すようなログは出ない。

このため、

• 実はssh-agentに秘密鍵Rがあった
• 公開鍵R'が削除されたから秘密鍵E2が使われるようになった

という事実が発覚しにくい。

要約

• 削除した鍵でもssh-agentに残っていることがある
• ssh-agentの鍵での接続が失敗するとほかの鍵にフォールバックされる

おまけ

どのGitHubアカウントが使われているか知りたかったら: SSHしてみよう by ChatGPT

ssh -T git@github.com

どの鍵でSSH接続しているか知りたかったら:-vオプション

ssh -v nanasi@localhost