Secure Shell

Secure Shell（セキュアシェル、SSH）は、暗号や認証技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。パスワードなどの認証を含むすべてのネットワーク上の通信が暗号化される。

概要

従来からTelnet、rsh、rloginなどリモートホストのシェルを利用するためのプロトコルは存在した。しかしながら、これらはネットワークに平文でパスワードを送信するため、パスワードを覗き見（盗聴）される危険性が高く、特にインターネット上では大きな問題であった。SSHは通信を暗号化した代替の通信プロトコルである。

オリジナルのSSHは、フィンランド出身のプログラマであるタトュ・ウルネン (Tatu Ylönen) により1995年に開発され、はじめフリーで公開された。しかし、同年12月には、SSH社 (SSH Communications Security) が設立され、プロプライエタリソフトウェアとなった。^[1]

ファイルコピー用のコマンドrcpを代替するscpや、FTPを代替するsftpも用意されている。

SSHの暗号通信はいわゆるハイブリッド暗号であり：

鍵交換アルゴリズム（ディフィー・ヘルマン鍵共有など）で共通鍵暗号のセッション鍵を生成し
共通鍵暗号（トリプルDES、AESなど）で通信を暗号化し
公開鍵暗号（RSAやDSA）でホストやユーザ認証を行なう

認証方式は公開鍵認証の他にも、パスワード認証、ワンタイムパスワードなどが提供されており、各個人/企業の情報セキュリティポリシーに合わせて選択できる。

なりすましを防止するための仕組みも充実している。

現在はバージョン1と2の2種類のプロトコルが共存している。バージョン1は既知の脆弱性があり推奨されない。

商用、自由ソフトウェア含めて幾つかの実装があり、特許や互換性の問題などでやや混乱があったが、2006年にSSHおよびその関連技術がRFCとして制定された^[2]。2008年の時点で最も普及しているのは、オープンソースのOpenSSHである^[3]。Linuxなどでも標準利用されており、現在では単にSSHと言った場合、OpenSSHの実装系を指すことが多い。

ソフトウェア

SSHサーバ

OpenSSH (マルチプラットフォーム)
SSH Tectia Server (マルチプラットフォーム)
Reflection for Secure IT(マルチプラットフォーム)
Dropbear (Unix系)

SSHクライアント

OpenSSH (マルチプラットフォーム)
PuTTY (Windows, UNIX)
Xshell (Windows)
Tera Term (Windows)
Poderosa (Windows)
RLogin (Windows)
SSH Tectia Client (マルチプラットフォーム)
Reflection for Secure IT(マルチプラットフォーム)
WebSSH

フィンガープリント

SSHフィンガープリント（エスエスエイチフィンガープリント）は、SSHプロトコルにおいて、サーバーの公開鍵を識別するために使用されるハッシュ関数（例: SHA-256）を用いて生成された短い文字列である。

SSHでサーバーに初めて接続する際、クライアント側では接続先が正規のサーバーであるかを判断できない。そのため、サーバーは自身の公開鍵をクライアントに送信し、クライアント側でその公開鍵のフィンガープリント（ハッシュ値）を利用して検証を行う。フィンガープリントは、短い文字列なので、目視で確認がしやすくなっており、これにより、利用者は接続先のサーバーが正しいものかを確認できる。SSH接続時にサーバ鍵のフィンガープリントを確認しないと、意図しないリモートコンピュータに接続している事に気づかず、通信内容を盗聴される恐れがある。

SSHサーバによっては、設定次第でブルートフォースアタックでシェルへのアクセスを許してしまう。IPAが発表している不正アクセスの届け出状況では、SSHポート経由でパスワードクラッキングが行われた例が繰り返し発表されている^[4]^[5]。「パスワード管理の徹底」「セキュリティパッチの適用」「アクセスログの監視による攻撃の迅速な発見」のような対策に加えて、公開鍵認証を採用することをIPAは推奨している。

2023年10月頃にTerrapin Attack（英語版）という中間者攻撃法が報告された^[6]。

ホスト認証

ホスト認証は、SSHクライアントがサーバーに接続する際に、そのサーバーがなりすましでないことを証明するプロセスである。この仕組みは、中間者攻撃を防ぐために不可欠である。ホスト認証のプロセスは以下の通りである。

クライアントがサーバーに接続を要求すると、サーバーは自身の公開鍵をクライアントに送信する。
クライアントは、受信した公開鍵が信頼できるものかを確認する。
1. 初回接続の場合、クライアントは受信した公開鍵のフィンガープリントを利用者に提示し、接続を許可するかを尋ねる。利用者がこれを承認すると、公開鍵はクライアントのローカルマシン（通常は `~/.ssh/known_hosts` ファイル）に保存される。
2. 2回目以降の接続では、クライアントは `known_hosts` に保存されている公開鍵と、サーバーから送られてきた公開鍵を比較し、一致すれば認証成功とみなす。
公開鍵の検証後、クライアントはランダムなデータを生成し、サーバーの公開鍵で暗号化してサーバーに送信する。
サーバーは、自身が持つ秘密鍵でそのデータを復号する。公開鍵で暗号化されたデータは、対となる秘密鍵でしか復号できない。
サーバーは復号したデータ（正確にはそのハッシュ値）をクライアントに送り返す。
クライアントは、送り返されてきたデータが自身が最初に生成したデータと一致することを確認する。これにより、サーバーが正しい秘密鍵の所有者、すなわち正規のサーバーであることが証明（Certificate）される。

これのプロセスにより、単に公開鍵を交換するだけでなく、サーバーが秘密鍵を確かに保有していることを検証し、通信の安全性を確保する。

フィンガープリントの確認

利用者は、SSH接続時に表示されたフィンガープリントが、接続しようとしているサーバーのものと一致するかを事前に確認することが推奨される。サーバー上でフィンガープリントを確認するには、`ssh-keygen` コマンドを使用する。例えば、CentOS 8の場合、ホストの公開鍵は `/etc/ssh/ssh_host_rsa_key.pub` に保存されている。コマンドを実行することで、サーバーに保存されている公開鍵のフィンガープリントを表示できる。

サーバーのホスト鍵が変更された場合

何らかの理由（サーバーの再構築やセキュリティポリシーの変更など）でサーバーのホスト鍵が変更された場合、クライアントが次回接続しようとすると警告メッセージが表示される。これは、`known_hosts` ファイルに保存されている古い公開鍵と、サーバーから新たに提示された公開鍵が一致しないために発生する。

この警告は、中間者攻撃の可能性を示唆するものでもあるため、注意が必要である。サーバー管理者が意図的に鍵を変更したことが確認できている場合に限り、クライアント側の `~/.ssh/known_hosts` ファイルから該当する古いホスト鍵の情報を削除する。情報を削除した後、再度SSH接続を試みると、初回接続時と同様のフィンガープリントの確認メッセージが表示される。ここで新しいフィンガープリントを承認することで、`known_hosts` ファイルが更新され、再び接続が可能となる。