0x90

一回休み

SSH鍵認証の仕組み

SSHの鍵認証といって、よくなされる説明は以下のようなものである。

  1. クライアントがサーバーに公開鍵を渡す
  2. サーバーがクライアントに公開鍵を渡す
  3. 公開鍵暗号で通信する

例えば2016年1月11日現在、「SSH 鍵認証 仕組み」でググると一番頭にくるここは、そんな感じの説明をしている。鍵のペアは確かに公開鍵と秘密鍵からなるので、一見正しそうな説明に見える。

しか~し

よくよく考えると、この説明はインチキであることがすぐわかる。ぱっと思いつくだけでも

  • 通信経路の暗号化と違うの?
  • 鍵認証にしなくてもすでに暗号化しているんじゃなかったっけ?
  • RSA以外によく使われている公開鍵暗号ってそんなにあるんだっけ?

とか、いくつもおかしな点がある。最大限好意的に解釈してもこの説明は単にパスワード認証してるのと同じじゃん!ってなる。

(正確には、SSHではSSLみたいに公開鍵認証を使って共通鍵をやり取りしてからセッションを始めるので、もっと複雑ではある。Triple DESなりAESのほうがRSAより処理が早いのだろう)

じゃあどうやって認証するの

RFCを見よう。RFCは英語だし量も多そうだし一瞬引いてしまうんだけど、ちゃんと読むところを読めば簡単。*1 まず親玉はこのひと。Referenceをみると、authに関しては4252を見よとあるので、見てみる。 「public」で検索して、この単語の密度が濃いあたりを重点的に読む。どんな形式の公開鍵を受け付けるかを問い合わせる方法の次に、認証方法が見つかる。公開鍵認証では、次のパケットで認証を行う。

  • byte SSH_MSG_USERAUTH_REQUEST
  • string user name
  • string service name
  • string "publickey"
  • boolean TRUE
  • string public key algorithm name
  • string public key to be used for authentication
  • string signature

ただし、signatureは次のデータをひとまとめにしたものに対する署名である。

  • string session identifier
  • byte SSH_MSG_USERAUTH_REQUEST
  • string user name
  • string service name
  • string "publickey"
  • boolean TRUE
  • string public key algorithm name
  • string public key to be used for authentication

これらの情報はサーバーも知っているので、署名を検証でき、さらに万一(とも最近あんま言えないけど)にも通信が盗聴されるようなことがあっても認証情報は漏れないよう*2になっていることがわかる。

まとめ

流石にSSHのパスワード認証はやめてください、とぼくはパスワード認証を見るたびに言っていますが、SSHのパスワード認証がはびこる一因は鍵認証に対する誤った認識が広まっていることもあるのではないかと思います。 ナイーブに考えてもパスワード認証と比べ明らかに鍵認証の次元のほうが広いですし、よそからの延焼を防ぐ、あるいはよそへの延焼を防ぐという意味でも、絶対に鍵認証を使うべきです。特に多人数で共用しているサーバーでは。

東大ですら末端の研究所レベルでは*3とんでもない有様なので、よそではもっとひどいんだろうなあ。。。

*1:とはいってもぼくもその昔某社RFCを読んだのがはじめてでしたが。

*2:もっともMITMで任意のコマンドを突っ込めるので単一のサーバーと言う意味では特に意味が無いが、延焼を防ぐという効果は期待できますね

*3:一応専任の職員がいるんだけど