SSH CA認証まとめ

SSHでの接続を、CA認証でやってみる。

備忘録として残しておくの。。。

概要

Open-SSH-5.4より、証明書を利用してログイン認証を行う、SSH CA認証が実装されました。

従来、サーバへのログインでは、公開鍵認証が一般的な認証方法ではありましたが、このCA認証の処理を追ってみて、どんないいことがあるのかとかに関してまとめておくのです。

SSH認証ではユーザ認証、サーバ認証とがあります。ユーザ認証では接続先サーバが接続元ユーザの認証を行い、サーバ認証では逆にユーザが接続先サーバが正しいかの認証を行います。
ここでは主にユーザ認証に焦点を絞って見ていくのです。（サーバ認証では、ユーザ認証でのユーザとサーバの立場を逆にして読み替える感じになります。また時間があったらまとめたい。）

SSHって？

おさらいとして、そもそものSSH（Secure Shell）ですが、２者間での通信時、やりとりされるデータを暗号化して認証を行うプロトコルとなります。

商用SSHからライセンス絡みのしがらみを取り除いき派生したOpenSSHが一般的によく利用されていますが、このOpenSSHではSSH1, SSH2の２種類のプロトコルが定義されています。各プロトコルによって暗号化方法は異なり、互換性はありません。

つまり、接続元、接続先ともに同じプロトコルでやり取りしあう必要があります。

SSH1(プロトコル１)

ここで登場する暗号鍵として、公開鍵暗号と共通鍵暗号の２つがあります。それぞれの特徴は以下のとおり。

処理の容易さから、なるべく共通鍵でデータの暗号化をしたいわけですが、そのためには共通鍵を２者間で共有する必要があり、その共有の際にネットワーク上に共通鍵が晒されてしまいます。
それはまずいので、共通鍵暗号化転送するために公開鍵暗号方式を利用し、公開鍵で共通鍵を暗号化してもらってから転送し、秘密鍵で復号します。

ということで、まとめると、SSHは公開鍵暗号方式、共通鍵暗号方式それぞれのメリットを活かしたプロトコルとなります。

SSL通信とかでもこれと似たような感じで暗号化通信を実現しています。

SSH認証は、このSSHでの認証となるので、以降で説明するデータのやり取りは基本的に暗号化されています。

また、公開鍵認証、CA認証でも、公開鍵暗号方式が用いられています。

SSH2（プロトコル２）

SSH1では共通鍵の２者間でのシェアのために公開鍵暗号を利用しましたが、SSH2ではDiffie-Hellman方式によって２者間での共通鍵シェアを実現します。

詳細はDiffie-Hellman鍵共有とかを見れば雰囲気わかるかと思いますので割愛しますが、接続元、接続先各々で公開鍵ペア（公開鍵＋秘密鍵）を生成し、

互いに公開鍵を交換し、自身の秘密鍵と交換した公開鍵から、２者間で共通の共通鍵を生成します。

この共通鍵を用いて暗号化通信を実現します。

SSH1よりもより安全性の高いアルゴリズムをサポートしていたりと、現在ではSSH2の利用が推奨されています。

公開鍵認証 VS CA認証

公開鍵認証とCA認証について、比較してみてみます。

公開鍵認証

まず公開鍵認証ですが、処理フローとしては以下のようになります。

接続元のユーザは公開鍵暗号の鍵ペア（公開鍵＋秘密鍵）を生成し、公開鍵を接続先サーバへ事前に配布しておきます。

その後、ユーザのログイン要求時、接続先サーバは、事前にユーザからもらっていた公開鍵で乱数を暗号化し、それをユーザへ返します。

ユーザは秘密鍵で復号し、サーバの生成した乱数を取得し、ハッシュ化してサーバへ返送し、サーバ側で検証されます。

暗号化した乱数を復号できるのは秘密鍵を持った接続元のユーザのみなので、それによって接続元ユーザの正しさが保証されます。

以上が公開鍵認証の流れとなります。

まとめると、ユーザは秘密鍵を、サーバはその秘密鍵に対応する公開鍵をそれぞれ認証承認のために必要とします。シンプルでなのです。

CA認証

次に本題の、CA認証の処理フローを見てみます。流れは以下の図のようになります。

公開鍵認証と違い、新たにCA（認証局）が登場します。CAは信頼される存在であり、サーバはこのCAを介して接続元ユーザが正しくアクセス権のある存在であることを検証します。

事前の準備として、公開鍵認証同様、接続元ユーザ側で公開鍵暗号の鍵ペア（ユーザ公開鍵＋ユーザ秘密鍵）を生成します。また、CAでも、署名用に公開鍵暗号の鍵ペア（CA公開鍵＋CA秘密鍵）を生成しておきます。

まず、ユーザは自身のユーザ公開鍵をCAに署名してもらいます。CAでは、このユーザ公開鍵を、CA秘密鍵を用いて署名します。ここでの署名ではオプションが指定でき、有効期限やら接続元IP、ユーザの制限やら色々設定できます。詳細は次のセクションで説明します。

んで、CAは署名に用いた秘密鍵の対のCA公開鍵を、接続先のサーバへ配布、登録しておきます。

そして、ユーザは接続先サーバへ接続時、CAに署名してもらった公開鍵（証明書）をまず渡します。

接続先サーバでは、CA公開鍵を用いてその署名済みユーザ公開鍵を検証します。（CA公開鍵で復号できるか＋署名内容的にアクセス可能か）

更に、公開鍵認証同様、ユーザが、「署名済み公開鍵に対応するユーザ秘密鍵」をちゃんと所持しているかも検証されます。

以上が処理の流れの概要となります。。。

まとめると、ユーザはユーザ秘密鍵と署名済みユーザ公開鍵(証明書)を、サーバはCA公開鍵をそれぞれ認証承認のために必要とします。

署名時のオプション

ここでは、CAでのユーザ公開鍵の署名時のオプションについて具体的に見てみます。署名は、下記コマンドによって実行されます。

 $ ssh-keygen -s <CA秘密鍵> -I <Specify> -n <principals> -z <シリアル番号> -V <有効期限> -O <オプション> <ユーザ公開鍵>

有効期限[-V]

証明書が有効な開始日時、終了日時を指定します。開始日時を指定しない場合は、現在から終了日時までが有効期限となります。

指定記法は以下の通り。

• 時刻指定　YYYYMMDDHHMMSS : (例) 20150320111111:20160320111111
  • 2015年3月20日11時11分11秒から2016年3月20日11時11分11秒まで有効
• 日付指定　YYYYMMDD : (例) 20150320:20160320
  • 2015年3月20日0時0分0秒から2016年3月20日0時0分0秒まで有効
• 相対日時指定 : (例) -1d:+1d
  • 昨日から明日まで有効

また、これらの記法を組み合わせることも可能です。

• (例) -1d:20160101

こんな感じで、かなり自由に設定できます。

注意点としては、この有効期限が検証されるのは、あくまでSSHリクエスト時のみとなります。なのでCA認証での期限内でのログイン後、証明書の期限が切れてもいきなりセッションがバツンと切れたりはせず、持続します。

もしリアルタイムに期限を効かせたい場合はそれ用の監視デーモンを作成するとか、Uber社がOSSで提供しているPAMモジュール（pam-ussh）のようなCA認証を各所に仕込む（sudoなど）とかになるかと思います。（どうせならOpenSSHでそこもサポートしてくれればなぁとか思ったり。。）

まあ漏洩時のリスクを最小限に抑えるならなるべく期限は短めにして、必要な時に都度発行するのが望ましい気はしますがね。

principal[-n]

CA認証での証明書には、署名時にprincipalとして任意の識別子を設定することができます。ログイン先サーバ側では、あらかじめ許可するprincipal一覧を設定しておくことで、ログインリクエスト時に提供される証明書内のprincipalがそのprincipal一覧に含まれているか検証されます。

principal一覧が未設定の場合はデフォルトでログイン要求してきたユーザ名が検証に充てられること（証明書のprincipalにユーザ名があるか）に注意です。

このprincipalをユーザ名に対応づけたり、または複数のユーザを束ねたグループ（Role）に紐づけたりして使うのがよくある使い方のようです。

通常ユーザがCAに証明書を発行してもらう際、何かしら認証が必要かと思いますが、そこでの認証ロジックだったり、ログイン先サーバでのprincipal一覧の管理方法等に応じて適宜どうするといい感じか考えると良さそうですね。

オプション[-O]

このオプションでは、ForceCommandやエージェントフォワード禁止・許可など、本来サーバ側のsshd_configで設定するようなことを証明書でできちゃいます。

CA側でこれらの制御ができるのはいろいろおもしろいことができそう。
詳細はssh-keygen manページをご参照くださいです。

ちなみにこの証明書での制御とログイン先サーバでの設定による制御

CA認証メリット・デメリット

ここまでいろいろ見てきましたが、結局のところ何がどううれしくなるのかについて観てみます。

CASE1　運用サーバが増えた・・・

公開鍵認証：追加されたサーバに対し、運用メンバ全員の公開鍵を登録する必要がある

ＣＡ認証：追加されたサーバに対し、ＣＡ公開鍵を登録するのみでＯＫ

CASE2　運用メンバーが増えた・・・

公開鍵認証：各運用サーバに対し、増えたメンバーの公開鍵をそれぞれ登録する必要がある

ＣＡ認証：増えたメンバーに対し、証明書を発行するだけでＯＫ

CASE3　鍵漏洩のリスクを最小限にしたい

 公開鍵認証：有効期限の制御は不可

ＣＡ認証：上述の通り設定可能。また、CA側に制御を寄せることができる

懸念点

ここまでいろいろなケースを観てみると、公開鍵認証よりＣＡ認証のほうがいいじゃんってなりそうですが、以下の問題点も考えられます。。

•  ＣＡの管理コストがかかる
• ＣＡ秘密鍵の漏洩リスク
• CAが障害点になりうる

まあ個人レベルの環境で特に特殊なアクセス制御など必要ないとすると、ＣＡ認証のメリットもそれほど享受されず、めんどくさいからもう公開鍵認証でいいやってなりそうな気がします。。

CA認証を実際に試してみる

通常、CA認証では接続元、接続先、認証局の３コンポーネント必要ですが、３つ用意するのもなかなかしんどいのでここでは全部１ホスト内で試してみます。

事前準備

まず、接続元（client）、認証局（CA）のワークスペースをディレクトリに切り、それぞれキーペアを作成します。

# ワークスペース作成
$ mkdir -p catest/{client,ca}

# client用のキーペア作成
$ ssh-kaygen -f catest/client/client.key

# CA用のキーペア作成
$ ssh-kaygen -f catest/ca/ca.key

CAでの署名処理

clientの公開鍵を、CAの秘密鍵で署名してみます。

# 有効期限: １日、principal: test-userで署名(test-userは適宜ログイン先サーバに存在するユーザ名に置き換えて)
$ ssh-keygen -s ./catest/ca/ca.key -I "ca test" -n "test-user" -z 0 -V +1d ./catest/client/client.key.pub

すると、client公開鍵のあるディレクトリ配下に証明書が生成されます。実際に証明書の中を確認してみます。

$ ssh-keygen -L -f catest/client/client.key-cert.pub
client.key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT 8f:39:b9:b5:50:0f:d3:0b:94:69:79:15:f6:a3:c6:1d
        Signing CA: RSA 53:58:74:1b:98:7d:96:42:b0:eb:65:33:d7:02:bd:06
        Key ID: "ca test"
        Serial: 0
        Valid: from 201X-01-03T03:14:00 to 201X-01-04T03:15:58
        Principals:
                test-user
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

ちゃんと意図した値が設定されてそうですね。

接続先サーバでの設定

今回は接続先サーバも同じサーバ内で賄うので、そのまま設定していきます。
設定はsshd_configに追記します。通常/etc/ssh/配下にあるはずです。

$ vim /etc/ssh/sshd_config
...
# 以下追記
TrustedUserCAKeys /etc/ssh/ca.key.pub
AuthorizedPrincipalsFile /etc/ssh/authorizedprincipals
...

TrustedUserCAKeys に証明書の検証に用いるCA公開鍵を、AuthorizedPrincipalsFile に許可するprincipal一覧が書かれたファイルをそれぞれ指定します。

上記の設定通り、ファイルを設置していきます。

# CA公開鍵を設置
$ sudo cp catest/ca/ca.key.pub /etc/ssh/

# principal許可リストを設置(開業区切りで複数指定可能)
$ sudo sh -c "echo test-user > /etc/ssh/authorizedprincipals"

最後に、sshdを再起動して設定を反映させます。ssh周りの設定はやらかすとログインできなくなったりなどもあるので反映前にチェックします。

# syntax check
$ sudo sshd -t
<何も出ないなら問題なし>

# 再起動
$ sudo service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

clientからログイン

それでは、諸々準備は整ったので最後にclientからSSHして確認してみます。

エージェントに既存の公開鍵が登録されているとわかりづらいので、削除してデバッグモードで試します。

# 既存のエージェント一式削除
$ ssh-add -D

# ssh リクエスト
# 利用する秘密鍵を指定することで、同一ディレクトリ内の「<秘密鍵>-cert.pub」が自動的に証明書として読み込まれます。
$ ssh -i ./catest/client/client.key test-user@kontany.net -vvv
...
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering RSA-CERT public key: rsa w/o comment
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa-cert-v01@openssh.com blen 1090
debug2: input_userauth_pk_ok: fp 8f:39:b9:b5:50:0f:d3:0b:94:69:79:15:f6:a3:c6:1d
debug3: sign_and_send_pubkey: RSA-CERT 8f:39:b9:b5:50:0f:d3:0b:94:69:79:15:f6:a3:c6:1d
debug1: Authentication succeeded (publickey).
...

debugログから、RSA-CERTのような文字列が確認できれば証明書による認証が行われていることになります。

まとめ

CA認証についてみていきました。鍵有効期限の制御やprincipalによる制御ができたり、サーバやユーザ追加などの環境変化にもスマートに対応できたりと、いろいろうまみがあります。このうまみは、特に比較的大規模環境の時真価を発揮しそうな感じですね。

しかし、個人環境レベルだと、CA管理コストやCA秘密鍵漏洩リスク、複雑さなどから、正直公開鍵認証で十分な気がします。

公開鍵認証、CA認証どっちがいいか、つまりは扱う環境の規模や、どうアクセス制限をかけたいか次第ってことかなと。

参考

• https://www.conoha.jp/blog/tech/3659.html
• http://www.unixuser.org/~euske/doc/openssh/jman/ssh-keygen.html