SSH とは

SSH (Secure Shell) とは、ネットワーク上のコンピュータに安全にリモート接続するためのプロトコルです。通信内容をすべて暗号化するため、パスワードやコマンドの内容が第三者に傍受されるリスクを排除します。

SSH が登場する以前は、Telnet や rlogin といったプロトコルが使われていましたが、これらは通信を平文 (暗号化なし) で送信するため、ネットワーク上の盗聴に対して無防備でした。1995 年にフィンランドの Tatu Ylönen が SSH を開発し、その後 OpenSSH としてオープンソース化されたことで、事実上の標準プロトコルとなりました。

現在、SSH はサーバー管理、クラウドインフラの操作、Git リポジトリへのアクセス、自動デプロイパイプラインなど、IT インフラのあらゆる場面で使われています。デフォルトのポート番号は 22 番です。

公開鍵認証の仕組み

SSH の認証方式で最も推奨されるのが公開鍵認証です。パスワードの代わりに、数学的に対になる 2 つの鍵 (公開鍵と秘密鍵) を使って本人確認を行います。

鍵ペアの生成: クライアント側で ssh-keygen コマンドを実行し、公開鍵と秘密鍵のペアを生成する。秘密鍵はクライアントに保管し、絶対に外部に漏らさない。
公開鍵の登録: 生成した公開鍵をサーバーの ~/.ssh/authorized_keys ファイルに登録する。
認証プロセス: 接続時、サーバーはランダムなチャレンジデータを生成し、クライアントに送信。クライアントは秘密鍵でチャレンジに署名し、サーバーは公開鍵で署名を検証する。秘密鍵そのものはネットワーク上を流れない。

設定が簡単だが、ブルートフォース攻撃に弱い。パスワードがネットワーク上を流れる (暗号化はされるが、サーバー側で平文に復元される)。

秘密鍵がネットワーク上を流れないため、盗聴されても安全。ブルートフォース攻撃が事実上不可能。パスフレーズを設定すれば、秘密鍵ファイルが漏洩しても即座に悪用されない。

鍵のアルゴリズムは Ed25519 が現在の推奨です。RSA も広く使われていますが、鍵長 4096 ビット以上が推奨されます。DSA と ECDSA (nistp256) はセキュリティ上の懸念から非推奨となっています。

ポートフォワーディング

SSH のポートフォワーディング (トンネリング) は、SSH の暗号化された接続を経由して、他のプロトコルの通信を安全に転送する機能です。

ローカルフォワーディング: クライアント側のポートへの接続を、SSH トンネル経由でリモートサーバー側の指定ポートに転送する。例: ssh -L 3306:db-server:3306 bastion で、ローカルの 3306 番ポートから踏み台サーバー経由でデータベースに接続。ファイアウォールで直接アクセスできないサービスへの接続に使う。
リモートフォワーディング: リモートサーバー側のポートへの接続を、SSH トンネル経由でクライアント側に転送する。NAT の内側にあるサーバーを外部に公開する場合などに使用。
ダイナミックフォワーディング: SSH 接続を SOCKS プロキシとして使用する。ssh -D 1080 server で、ブラウザのプロキシ設定を localhost:1080 に向ければ、すべての Web 通信が SSH トンネル経由になる。公衆 Wi-Fi での通信保護に有効。

ポートフォワーディングは、VPN を構築するほどではないが特定のサービスへの安全な接続が必要な場面で重宝します。踏み台サーバー (Bastion Host) を経由した多段 SSH 接続も、~/.ssh/config の ProxyJump ディレクティブで簡潔に設定できます。

SCP と SFTP によるファイル転送

SSH の暗号化チャネルを利用したファイル転送プロトコルとして、SCP と SFTP があります。

コマンド 1 つでファイルをコピーできるシンプルなツール。scp file.txt user@server:/path/ のように使う。転送の中断・再開ができず、ディレクトリの同期には向かない。OpenSSH 9.0 以降では内部的に SFTP プロトコルを使用するようになった。

FTP に似た対話的なファイル操作が可能。ディレクトリの一覧表示、ファイルの削除・リネーム、転送の中断・再開に対応。GUI クライアント (WinSCP、FileZilla、Cyberduck) も豊富。名前が似ているが FTPS (FTP over TLS) とは別のプロトコル。

従来の FTP はパスワードとファイル内容を平文で送信するため、現在ではセキュリティ上の理由から SFTP への移行が強く推奨されています。レガシーシステムとの互換性が必要な場合を除き、新規構築では SFTP を選択すべきです。

SSH セキュリティベストプラクティス

SSH はデフォルト設定のままでも暗号化通信を提供しますが、本番環境では以下の設定を施すことで攻撃リスクを大幅に低減できます。

パスワード認証を無効化する: /etc/ssh/sshd_config で PasswordAuthentication no を設定し、公開鍵認証のみを許可する。これだけでブルートフォース攻撃の大半を無効化できる。
root ログインを禁止する: PermitRootLogin no を設定し、一般ユーザーでログイン後に sudo で権限昇格する運用にする。
ポート番号を変更する: デフォルトの 22 番から別のポートに変更する。セキュリティの本質的な強化にはならないが、自動スキャンによる攻撃試行を大幅に減らせる。
接続元 IP を制限する: ファイアウォールで SSH ポートへのアクセスを特定の IP アドレスに限定する。クラウド環境ではセキュリティグループで制御する。
Fail2ban を導入する: 認証失敗が一定回数を超えた IP アドレスを自動的にブロックするツール。ブルートフォース攻撃への有効な対策。
鍵のローテーション: 定期的に SSH 鍵を更新し、退職者や不要になった鍵を authorized_keys から速やかに削除する。鍵の棚卸しを怠ると、退職者が引き続きサーバーにアクセスできる状態が放置される。

よくある誤解

SSH はサーバー管理者だけが使うもの: 開発者が Git リポジトリにアクセスする際 (git@github.com:...)、CI/CD パイプラインがデプロイ先に接続する際、データサイエンティストがリモートの GPU サーバーで作業する際など、IT に関わるあらゆる職種が日常的に SSH を利用しています。
SSH のポート番号を変えればセキュリティは万全: ポート変更は自動スキャンを減らす効果がありますが、ポートスキャンで容易に発見されるため、本質的なセキュリティ対策にはなりません。公開鍵認証の強制、パスワード認証の無効化、接続元 IP の制限など、複数の対策を組み合わせることが重要です。
SSH 鍵は一度作れば永久に使える: SSH 鍵にも有効期限の概念を持たせるべきです。退職者の鍵の削除漏れ、秘密鍵の漏洩リスク、暗号アルゴリズムの陳腐化などを考慮し、定期的な鍵のローテーションと棚卸しが推奨されます。

SSH (Secure Shell)