SSHで公開鍵暗号方式の仕組み

今までなんとなく利用してきた鍵ファイルを使ったサーバとの通信。

このたび認識を改めたいと思います。

※下記文章だけですが、いずれ絵とか入れて分かりやすくしたいと思いますー

■公開鍵暗号方式
ペアの公開鍵と秘密鍵を使った暗号化方式のことです。

鍵の生成方法は今回省略します。

■公開鍵暗号方式の仕組み
説明する上での登場人物を紹介します。

Mr.Sasa（クライアント）
Mr.Kure（クライント）
Cork（サーバ　愛犬の名前こるく）

＜挿絵予定＞

SasaとKureがCorkと公開鍵暗号方式で通信するために用意するもの

それはSasaとKureはそれぞれの鍵です。

Sasaが作ったもの
･Sasaの公開鍵
･Sasaの秘密鍵

Kureが作ったもの
･Kureの公開鍵
･Kureの秘密鍵

＜挿絵予定＞

＜挿絵予定＞

それぞれ公開鍵を持っていますが、これはネット上に流出しようが構いません。
なぜならこの公開鍵では「暗号化」しか出来ないからです。

その代わり秘密鍵はしっかりと自分だけ持っていて下さい。
なぜなら自分の公開鍵が暗号化したものを「複合化」出来るのは自分の秘密鍵だけですから。

＜挿絵予定＞

Sasaは自分の公開鍵をCorkに渡します。
※設定については後で説明します。

公開鍵は上記理由でセキュリティを意識する必要がないため、メールでもWebサイト経由でも構いません。とにかくCorkに渡します。

Cork（サーバ）はSasa（クライアント）からのリクエストに対してSasaの公開鍵で暗号化してレスポンスします。

この暗号化されたデータですが、Sasa自身は秘密鍵で複合化する事ができます。

＜挿絵予定＞

いったんここで鍵暗号方式に起こりうるセキュリティ被害を考えてみます。

Kureがこの通信を盗聴してたとしてもKureの秘密鍵では複合化できず、通信内容は分かりません。

しかし、KureがもしもSasaの秘密鍵を手に入れていたら通信内容が分かります。

＜挿絵予定＞

また、Corkに保管されているSasaの公開鍵がこっそりKureの公開鍵に置き換えられてしまったら、
CorkはSasaと通信しているつもりが、いつのまにかKureと通信してた　なんてこともありえます。

＜挿絵予定＞

こういったセキュリティ被害が起こらないよう

SasaやKure（クライアント）は秘密鍵の保管に細心の注意を、Cork（サーバ）は公開鍵のすり替えが行われないように注意する必要があります。

■通信は双方向ですよっと
上記説明だけだと Cork（サーバ）からSasa（クライアント）への通信は暗号化されますが、逆は？ってなりますよね。

＜挿絵予定＞

実は逆も同じように鍵による暗号と複合が行われています。

そもそもこの公開鍵暗号方式を使うにはCorkがSSHサーバーになっている事が前提です。

SSHサーバとは
僕はOpenSSHしか知りませんが、これがインストールされていて、sshd（デーモン）が起動しているサーバのことです。

SSHサーバはクライアントと同じように鍵を持っています。

Cork（サーバ）が持ってるもの
･Corkの公開鍵
･Corkの秘密鍵

＜挿絵予定＞

実はSasaがCorkにアクセスする際にCorkからCorkの公開鍵が渡されているんです。
※teraterm等のターミナルでアクセスすると、このホストの公開鍵を保存しますか？的な確認があったりします。

＜挿絵予定＞

というわけで、お互いがお互いの鍵を使って暗号化していたのです。

■鍵の保管
サーバはユーザ毎の公開鍵をこんなところに保管します。
/home/ユーザ名/.ssh/authorized_keys

この時の権限は600にして下さい。
644とかではいけません。

＜挿絵予定＞

ユーザ本人のみ権限がある状態下でないと利用出来ないなんて少し感動です。

ちなみにauthなんちゃらkeysには複数の鍵ファイルを保管できます。

保管といってもauthorizedkeysはディレクトリではなくファイルなので、１行が１鍵というように鍵の分だけ改行していきます。

＜挿絵予定＞

このauthorized_keysというファイル名は/etc/ssh/sshd_configで指定しています。
↓こんなふうに

#AuthorizedKeysFile     .ssh/authorized_keys

sshの設定については次回書きたいと思います。

とにかく、鍵の仕組みとsshの設定を熟知したうえで利用しないといつかひどい目に遭う

そう感じました。