はじめに

背景

これを知っていたからと言って何かの役に立つかというと、そうでない人の方が多いとは思うのですが、いい加減、SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな、ということで記事にしました。

SSHについて

皆さんご存知の通り、SSHはSecureSHellの略であり、暗号によって保護された通信を通じて遠隔操作を行う¹アプリケーション、またはプロトコル²を指します。
Linux等のUNIX系OSの遠隔操作³、またはネットワーク機器の管理に広く使われており、その実装としてはOpenSSHが有名です。

ところでSSHには、接続してきたユーザが誰なのかを識別する認証機能があり、その方式としてパスワード認証と並んで最もメジャーなのが公開鍵暗号を用いる公開鍵認証です。⁴

しかし…。残念なことに、公開鍵認証の設定や使い方はともかくとして、その仕組みに対する説明⁵はかなり誤りが多い状況なのです。⁶

公開鍵認証の仕組み

良くある説明

例として、IBM developerWorksのOpenSSH キー（鍵）の管理: 第 1 回(2001年)を取り上げてみます。⁷
※強調は@angel_p_57による

ここから先がかなりおもしろいところです。Remoteboxのsshdは乱数を生成、先にコピーしておいた公開鍵を使用してそれを暗号化します。次いで、この暗号化した乱数をlocalboxで実行されているsshに送り返します。それを受けてsshは、私有鍵を使用してこの乱数の暗号化を解除してそれをremoteboxに送り返します。これは要するに「ほら、対応する私有鍵を間違いなく持っていますよ。メッセージの暗号化を解除できましたよ。」と言っていることになります。最終的にsshdは、このsshが対応する私有鍵を所有していることから、ログインを許可してよいと判断します。

これを図にすると次のようになると言えます。が、これは完全な誤りなのです。

巷に出回っている説明は、細かい違いはあれど、大体これに該当します。

…なぜこれが間違っているのか? それは実態に合ってないからという他はないのですが、実態を知らなくてももっと単純に判断できます。
それは、公開鍵認証に使うのは電子署名の鍵⁸であって、そもそも暗号化・復号という機能を想定していないものだということ。なので、このような仕組みになるはずがないのです。

妥当な説明

ということで、正しくは電子署名をどう使うかという説明になるはずです。
概要としては次の図のようになります。

単純に言うと、ユーザが自身の秘密鍵を使って署名を生成し、その署名をサーバ側が公開鍵を使って検証できれば、その署名は確かに正当なユーザが作成したものだからと判断し、認証成功ということです。もちろん、ユーザと公開鍵との対応が適切かどうかも照合を行います。

ただし注意が必要なのは、認証の前の鍵交換、中でもその手続きによって共有されるセッションIDが絡んでくることです。
鍵交換はDHやECDHといった鍵交換方式⁹により行われ、第三者には推測困難な状態¹⁰で秘密情報を共有します。セッションIDはその秘密情報から導出されますが、同時に当事者にすら内容のコントロールが困難な、つまり狙った値を故意に作り出せないようにされています。

このセッションIDを署名対象データに混ぜておくことで、認証のために生成した署名が流用されることを防ぐのです。
※巷に出回っている誤った説明は、実態と合ってないという点が一番の問題ですが、この流用への対策に相当する考慮が全くないという点も問題と言えます。

公開鍵認証の特長

本当に公開鍵認証の方が良い?

巷では「パスワード認証よりも公開鍵認証の方が安全で良い」と言われますが、果たして本当でしょうか?

結論から言えば、公開鍵認証の方が良いと言って差し支えないと思います。
が、結論が同じとは言え、そこに至る理由にも、一般で言われているものとは多少の相違がありますので、本記事で取り上げていきたいと思います。

公開鍵認証とパスワード認証の違い

先に公開鍵認証とパスワード認証の違い、そして公開鍵認証のメリットを説明します。

公開鍵認証において、サーバに登録するのはユーザの公開鍵です。そして、認証時には秘密鍵そのものではなく、生成した署名データ、それも流用困難なものをサーバに提示します。そのため第三者はもちろんサーバであっても秘密鍵を入手したり、署名を悪用することは困難です。
一方で、パスワード認証の場合、認証時にはパスワードそのものをサーバに提示します。この認証フェーズでは既に通信が暗号で保護されていますので、第三者にパスワードが盗聴されるわけではありませんが、当のサーバに悪意があり¹¹かつ他所で同じパスワードを使用している場合、パスワード漏洩・他所への悪用のリスクがあります。

つまり公開鍵認証最大のメリットは、パスワード認証に使うパスワードと違って同一の鍵を各所に使い回すことにリスクがほぼないことです。¹²

もちろん、パスワード認証の場合、うっかりパスワードを取り違えてつい他所用のパスワードをサーバに漏らしてしまったり、管理が面倒になってつい同じパスワードを使い回してしまったり、そもそも人間の頭で覚えて使おうとするあまりつい強度の不十分なパスワードを使ってしまったりという、極めて人間臭いリスクもないとは言えず、公開鍵認証にはフールプルーフ(意訳:「ついうっかり」対処)的なメリットも現実には大きいのかもしれませんが、技術上は本質的なものではないことにご注意ください。

良くある理由付け

では今度は、巷で良く言われる理由付けを取り上げたいと思います。

例えば、レンタルサーバ等のサービスで有名なさくらインターネットのナレッジには次のようにあります。

現時点(※パスワード認証が有効な状態)では、(略)パスワードが分かれば誰でもログインできてしまいます。
(略)
これにより(※公開鍵認証のみ有効な状態にすることで)、パスワード総当り攻撃などで第三者に不正にsshのログインを試みられても、鍵が盗まれない限り破られることはありません。

なお※は@angel_p_57による補足です。

まず「(パスワード認証が有効なら)パスワードが分かれば誰でもログインできる」これは確かにその通りですが、公開鍵認証であっても、当人と同じ秘密鍵を持てば誰でもログインできることには変わりません。秘密鍵と言えど、一般のパスワードと同じくテキストとして表現可能なデータですから、パスワードはどこでも使える一方で秘密鍵は特定のマシンでしか使えないとするのは偏りのある説明です。

また「パスワード総当り攻撃など」と脅威を挙げていますが、それで問題になるのは脆弱なパスワードを設定していることが前提です。
十分な強度を持たせたパスワードであれば総当たり攻撃が脅威になるレベルではありませんし¹³、それを言うのであれば、DSAやECDSAといった方式では、鍵の中でも核となる小さな秘密情報さえあれば鍵を復元することは可能¹⁴ですから、その秘密情報を総当たりして鍵を試すような攻撃も問題視するはめになるでしょう。

ということで、なぜ公開鍵認証の方が安全かの説明になっていないのです。

…ただ恐らくは、このような説明が出回るのには、パスワードというものは人間の記憶できる範囲で設定する、ある程度推測可能な代物なのだという前提があるのでしょう。
実際にそのように扱われている面もあろうかとは思いますが、ユーザのパスワードの取り扱いに対する意識の問題と認証方式自体の問題とは区別すべきかと思います。¹⁵

なお、たまに「パスワード認証は平文でパスワードが流れる」と説明しているところもありますが、前項で説明した通り、認証のフェーズでは既に通信自体が暗号で保護されていますから、「平文」というのは不適切です。

終わりに

まとめ

というわけでまとめです。

公開鍵認証は、署名を提示できるのが秘密鍵の所有者のみという電子署名の性質を利用した認証方式である。
良くある説明、「公開鍵認証では乱数を公開鍵で暗号化し…」は誤りである。
公開鍵認証の、パスワード認証と比較したメリットは、同一の鍵を各所の認証に使い回すことのリスクがほぼないことである。
良くある説明での、「公開鍵認証の方が安全」の理由付けは、むしろユーザが適切なパスワード取り扱いをできないことを前提としており、技術的に妥当とは言い辛い。

もっと詳しく知りたい方や、話の裏を取りたい方には、脚注にもあるRFC4252の和訳を一読されることをお勧めします。

SSHの機能: 遠隔操作の中には、scpやsftpといったファイル転送機能もあります。更に遠隔操作を行うのみにとどまらず、通信を内部的に多重チャネル化して扱うことで、VPNめいた通信のトンネル機能も実現します。 ↩
SSHプロトコル: SSHプロトコルには、バージョン1(1.5),2の2種類が存在しますが、1は遠い昔に非推奨となっており、まず全く使われていないはずなので、全て2の話だと思ってください。というか、1の方は正式なRFCにすらなっていません。 ↩
遠隔操作: 近年だと、githubをはじめとするオンラインのgitリポジトリを操作するという目的で、なじみ深い方も多いかもしれません。 ↩
認証の種類: パスワード認証、公開鍵認証の他に、ホストベース認証、キーボードインタラクティブ認証、GSSAPI認証があります。最後の2つについてはSSHアプリケーションが独自に認証を行うというよりも、外部のライブラリ等と連携して認証を実現することを想定した方式です。キーボードインタラクティブ認証は「チャレンジレスポンス」の方が通りが良いかも知れません。ワンタイムパスワードで認証するために使われたりします。GSSAPIはKerberos(Windows Active Directory含む)との連携が主となるようです。 ↩
仕組みに対する説明: sshアプリケーションを実際に作成する人でなければ、仕組みを誤って認識していたとしても実害は無いとも言えるのですが。ただ、デマの再拡大の元にはなるので、個人的には気持ち悪いところです。 ↩
ほとんど全て: 各種技術情報サイトも壊滅的です。とは言えもちろん、sshアプリケーションのマニュアル(流石に)含め、適切な説明のものも存在します。例えば日本語でちょっと検索した感じだと次の通り。 ↩
- PuTTYマニュアル
- ssh.comのSSH Tectia Clientマニュアル
- atmarkITの実践でも役立つLPICドリル
- ブログEngineer of the lawyer
- 書籍ゼロからはじめるLinuxサーバー構築・運用ガイド動かしながら学ぶWebサーバーの作り方
- 意外だったのが、情報処理技術者試験H29秋過去問
- また、東京電機大学のSSHの進化、こちらは情報こそ古いものの、廃れたSSHv1との比較情報があり、今では逆に貴重と言えます。
- 最後に、日本人として情報の翻訳等OpenSSHに関わってこられた春山氏によるRFC4252の和訳(というかこれだけ読めば良いって話もあるんですが)
IBMの記事を取り上げた理由: 2001年と古い記事ながらなぜ取り上げたかと言うと、根本的に今出回っている説明がここから変わっていない点と、既に当時稲村氏により公開鍵暗号による Challenge & Responseって？という記事で誤りを指摘されていたという経緯があるからです。 ↩
電子署名の鍵: 現在SSHで使用できる方式としては、RSA,DSA,ECDSA,EdDSA(ed25519)です。これら電子署名も、(広義の)公開鍵暗号の1種です。暗号化・復号の機能を持つのは狭義の公開鍵暗号であり別物です(RSAに限っては電子署名用の鍵を暗号用に流用もできるのですが)。「いや電子署名でも暗号化とかあるんじゃないの」という人は、拙記事電子署名の基礎知識や、「電子署名=『秘密鍵で暗号化』」という良くある誤解の話をご参照ください。 ↩
鍵交換方式: DHやECDHといった鍵交換方式も、広義の公開鍵暗号に分類される技術です。 ↩
第三者には推測困難: とは言え、通信相手が識別できていなければ「第三者」もへったくれもないので、鍵交換と同時にホスト認証が行われ、サーバが何者であるかをユーザが識別します。もし識別をさぼった場合には、なりすまし(中間者攻撃含む)による通信の乗っ取りを許してしまう恐れがあります。 ↩
サーバの悪意: 「SSHサービス提供側を疑えってのか!」と思われるかも知れませんが、サーバ側が例えば乗っ取られた場合のことも含めたリスクの話をしています。 ↩
同一の鍵を各所に: なので当然、自分の公開鍵を文字通り公開することにもリスクは特にありません。どこかで「公開鍵と言えどサーバに登録する以外で公開すべきではない」という意見を見た記憶があるのですが、的外れと言えましょう。 ↩
パスワードの強度: 最近のLinuxの場合、512bitのハッシュ化パスワードをサポートしますから、十分に長いパスワードを設定すれば256bitの強度を見込むことができます。一方で、OpenSSHでのECDSAのデフォルトは256bit鍵で、これは128bitの強度に相当します(参考:鍵長に対するNISTのレポート)。だから単純にパスワードの方が良いということはないのですが、総当たりに対する強度は十分に有しうるということです。 ↩
鍵の復元: 拙記事ECDSA鍵の復元テストでECDSAの鍵を復元する話を挙げています。なお、だからといってECDSAという方式に問題があると主張しているわけではないので念のため。鍵データのファイルサイズは数百バイトオーダーになりますが、そのコアとなるのはせいぜい数十バイト程度ですよということです。 ↩
区別すべき: 実際のところはそのような話は百も承知で、ただ、「一般のユーザが適切にパスワードを扱えるわけねぇだろ!! だから禁止にしてしまえ!」とストレートに言えないがために、敢えて婉曲表現をしている可能性は否定できません。 ↩

SSHの公開鍵認証における良くある誤解の話