user@server:~$ ssh [email protected]Welcome to server.Last login: 2026-05-26$ █

セキュア シェル (SSH)

11 最小読み取りネットワーキング

SSH は、インターネットの目に見えない部分、つまりすべてのシステム管理者のリモート コンソール、すべての開発者のデプロイ ステップ、プライベート リポジトリへのすべての Git プッシュを実行するプロトコルです。 1990 年代後半に Telnet に取って代わり、それ以来、デフォルトのセキュアシェル プロトコルとして使用されています。実際に何を行うのかを理解すれば、多くの操作作業が意味のあるものになります。

記事全文は以下に英語で記載されています。

SSH (セキュア シェル) は、セキュリティで保護されていないネットワーク上でネットワーク サービスを安全に運用するための暗号化ネットワーク プロトコルです。最も一般的には、リモート コマンド ライン ログイン (名前に「シェル」) とファイル転送に使用されますが、基礎となるプロトコルは、あらゆる TCP アプリケーションをトンネリングできるほど汎用的です。 SSH は、1995 年に大学でのパスワード スニッフィング攻撃を受けて Tatu Ylönen によって作成されました。 OpenSSH 実装 (1999 年開始) は、現在最も導入されているバージョンです。

SSH が提供するもの

3 つのプロパティ:

  • 機密性 — 転送中に暗号化されます。ネットワーク オブザーバーには、コマンドやパスワードではなく、暗号化されたバイトが表示されます。
  • Integrity — 変更されたパケットが検出され、拒否されます。
  • 両端の認証 — クライアントはサーバーに対して認証し (パスワード、公開キー、またはその他の方法)、サーバーはクライアントに対して (ホスト経由で) 認証します。

この組み合わせは、Telnet、rlogin、rsh、および rcp の古いスイートを置き換えます。これらはすべて平文で認証情報を送信します。

SSH 接続の仕組み

ハンドシェイク (簡略化):

  1. Cクライアントはサーバーへの TCP 接続を開きます。ポート 22 (構成可能)。
  2. 両側でバージョン文字列を交換します。
  3. 両側でサポートされているアルゴリズムを交換します。最も強力な相互暗号である KEX、MAC.
  4. Key 交換を選択します。最近では通常、X25519 または NIST 曲線が使用されます。双方とも、平文でネットワークを通過することなく、共有秘密を導出します。
  5. サーバーは、共有秘密で署名されたホスト キーを送信します。クライアントは、~/.ssh/known_hosts に対してチェックします。
  6. この時点から、共有秘​​密から派生したキーを使用してすべてが暗号化されます。
  7. クライアントは、パスワード、公開キー、またはその他のメカニズムによって認証します。
  8. 暗号化されたセッションが開かれます。クライアントは、シェル、ファイル転送、ポート転送など、実際に必要なものを要求します。

認証メソッド

  • パスワード。 ユーザーはパスワードを入力します。セッション内では暗号化されて送信されます。シンプルですが、公開された SSH サーバーに対するクレデンシャル スタッフィング攻撃に対して脆弱です。
  • 公開キー。 クライアントには秘密キーがあります (通常、~/.ssh/id_ed25519)。サーバーには、~/.ssh/authorized_keys に一致する公開キーがあります。クライアントは、サーバーからのチャレンジに署名することで、秘密キーの所有を証明します。パスワードがネットワークを通過することはありません。ほぼすべてのユースケースで推奨されるデフォルト。
  • 証明書ベース。 CA は、有効期限と制約を含む、ユーザーのキーの証明書に署名します。サーバーは CA を信頼し、署名された証明書を自動的に信頼します。多くのユーザーを抱える組織に最適なモデル。 ssh-key-distribution nightmare.
  • FIDO2 / hardware-key SSH. を置き換えます。 最近の OpenSSH は、ハードウェア セキュリティ トークンに裏付けされたキーをサポートしています。フィッシング防止、物理的な所有が必要。
  • 多要素 — 上記を組み合わせます。パスワード + キー、またはパスワード + ハードウェア トークン。

シェル アクセスを超えて: ポート フォワーディング

SSH は、暗号化されたセッションを通じて任意の TCP トラフィックをトンネリングできます:

  • ローカル ポート フォワーディング (-L): ssh -L 9000:internal:3306 user@bastion はローカル ポート 9000 を開き、要塞ホスト経由で internal:3306 にトンネルします。ジャンプ ホスト経由で内部サービスにアクセスする場合に便利です。
  • リモート ポート転送 (-R): 逆方向。リモート ホストは、マシン上のサービスにトンネルで戻るポートを取得します。
  • 動的ポート転送 (-D): SSH はローカル マシン上に SOCKS5 プロキシを作成します。これを指すアプリケーションはすべて、その TCP トラフィックが SSH セッションを介してトンネリングされます。事実上、SSH を介したシングルユーザー VPN。

SSH 動的転送は、最も有用な貧困層向け VPN です。どこかにサーバーを持っている人は誰でもそれにアクセスできます。

OpenSSH エコシステム

  • ssh — クライアント
  • sshd — サーバー デーモン
  • scp — セキュア コピー (レガシー、現在はほとんどが sftp に置き換えられています) Hood)
  • sftp — セキュア FTP、SSH
  • ssh-agent — 復号化されたキーをメモリにキャッシュするため、接続ごとにパスフレーズを入力する必要がなくなります
  • ssh-keygen — 生成キーペア
  • ssh-copy-id - 公開キーをリモートのauthorized_keysファイルにコピーします

SSHサーバーの防御

公共のインターネット上のSSHサーバーは、クレデンシャルスタッフィングスキャンを常に監視します。防御策:

  • パスワード認証を無効にする。公開キーのみ。クレデンシャルスタッフィング攻撃ベクトル全体を削除します。
  • Ed25519 キーを使用します。 最新、高速、小型。 ssh-keygen -t ed25519 は、新しいキーに適したコマンドです。
  • デフォルト以外のポートを使用します。 マージナル。スキャナーのログ ノイズをほとんど軽減します。
  • fail2ban または sshguard - 試行が繰り返し失敗した後に IP をブロックします。
  • SSH できるユーザー アカウントを制限します。 AllowUsers in sshd_config.
  • VPN または Tailscale — 回避できる場合は、SSH をパブリック インターネットにまったく公開しないでください。
  • known_hosts とauthorized_keys を監査します。 離脱したユーザーのキーを削除します。予期しないエントリがないか確認してください。

よくある質問

SSH はどのポートを使用しますか?
デフォルトでは 22 です。ポートは構成可能です。一部の通信事業者は、ログ内のスキャン トラフィックを削減するために SSH を非標準ポートに移動します。これは隠蔽によるセキュリティです。実際のセキュリティではなく、衛生上役立ちます。本当のセキュリティは強力な認証です。
SSH は HTTPS より安全ですか?
さまざまな脅威モデル。どちらも最新の暗号化を使用しており、プロトコル レベルでは本質的に同等に安全です。 SSH は通常、公開キー認証 (パスワードなし、非常に強力) で使用されますが、多くの HTTPS サイトでは依然としてパスワード認証 (デフォルトでは弱い) が使用されます。プロトコルはピアです。導入方法はさまざまです。
ファイル転送に SSH を使用できますか?
はい。 <code>scp</code> と <code>sftp</code> は両方とも SSH 経由で実行されます。 SFTP は、再開可能な転送、再帰的操作、アトミックな書き込みなど、より高機能な最新の選択肢です。 <code>rsync</code> はトランスポートとして SSH を使用することもでき、重要な転送に最適なツールです。
SSHキーとは何ですか?
認証に使用される公開キーと秘密キーのペア。秘密キーはマシン上の <code>~/.ssh/id_*</code> にあります。公開キーは、接続するサーバーの <code>~/.ssh/authorized_keys</code> にインストールされます。パスフレーズのない秘密キーを紛失すると、秘密キーを持っている人は誰でもあなたとしてログインできてしまうため、深刻な問題になります。 SSH キーは常にパスフレーズで保護してください。
SSH で「ホスト キーが変更されました」と表示されるのはなぜですか?
前回の接続以降、サーバーの ID キーが変更されました。サーバーが再構築されたか、キーがローテーションされたか、または何かが間違っています (最も懸念されるケース: 誰かがサーバーになりすましている)。新しいキーを盲目的に受け入れないでください。サーバーオペレーターに帯域外で確認してください。正当なローテーションの場合は、known_hosts から古いキーを削除し、新しいキーを受け入れます。
SSH の説明: Secure Shell がどのようにして Telnet を置き換えたのか、そして各 SSH セッションの内部には何があるのか