SSHの基礎と安全な運用方法

結論

SSHは、サーバへ安全にログインし、コマンド実行、ファイル転送、ポートフォワーディングを行うための基本的なプロトコルである。単に「リモートログインの道具」として使うだけでなく、認証、暗号化、ホスト検証、権限管理を理解して運用する必要がある。

実務では、パスワードログインに依存せず、公開鍵認証を基本とする。さらに、sshd_config によるログイン制限、秘密鍵の保護、known_hosts の確認、不要な転送機能の制限を組み合わせることで、安全性を高められる。SSHの仕様はRFC 4251からRFC 4254で整理され、OpenSSHは現在広く使われる実装である。(RFCエディタ)

SSHとは何か

SSHは「Secure Shell」の略であり、ネットワーク越しに別のコンピュータへ安全に接続するためのプロトコルである。Telnetやrloginのような古い平文ベースのリモートログイン手段と異なり、通信内容を暗号化する点が重要である。

SSHでよく使われる用途は以下である。

リモートサーバへのログイン
リモートコマンドの実行
scp や sftp によるファイル転送
ローカルポートフォワーディング
リモートポートフォワーディング
Gitサーバへの接続
踏み台サーバ経由の接続

OpenSSHの公式マニュアルでは、ssh は基本的なクライアントプログラム、sshd はログインを受け付けるデーモンとして説明されている。(OpenSSH)

SSHの基本構造

SSHは単一の機能ではなく、複数の層から成るプロトコル群である。RFCでは主に次の要素に分けられる。

要素	役割
Transport Layer Protocol	暗号化、完全性確認、サーバ認証の基盤を提供する
User Authentication Protocol	ユーザー認証を扱う
Connection Protocol	複数のチャネル、シェル、コマンド実行、ポート転送などを扱う

この分離により、SSHは単なるログインだけでなく、ファイル転送やトンネリングにも利用できる。SSH接続の中では「チャネル」という単位でセッションや転送を多重化できるため、1つのSSH接続上で複数の用途を扱える。(RFCエディタ)

基本的な使い方

最も基本的な接続は次の形式である。

ssh [email protected]

ポート番号を指定する場合は -p を使う。

ssh -p 2222 [email protected]

リモートで単発のコマンドを実行する場合は、接続先の後ろにコマンドを書く。

ssh [email protected] "uptime"

秘密鍵を明示する場合は -i を使う。

ssh -i ~/.ssh/id_ed25519 [email protected]

頻繁に使う接続先は ~/.ssh/config にまとめるとよい。OpenSSHの ssh_config では、設定はコマンドラインオプション、ユーザー設定ファイル、システム全体の設定ファイルの順で読み込まれる。(OpenBSD Manual Pages)

Host app-server
  HostName example.com
  User deploy
  Port 22
  IdentityFile ~/.ssh/id_ed25519

この設定を置くと、次のように短く接続できる。

ssh app-server

公開鍵認証の仕組み

SSHの認証では、パスワード認証よりも公開鍵認証がよく使われる。公開鍵認証では、秘密鍵と公開鍵のペアを使う。

秘密鍵はクライアント側に保管する
公開鍵はサーバ側の ~/.ssh/authorized_keys に登録する
ログイン時に、秘密鍵そのものをネットワークへ送信しない
サーバは公開鍵と署名を使って、接続者が対応する秘密鍵を持つことを確認する

鍵を作成する例は次の通りである。

ssh-keygen -t ed25519 -C "[email protected]"

作成後、公開鍵をサーバへ登録する。

ssh-copy-id [email protected]

ssh-copy-id が使えない環境では、公開鍵の内容をサーバ側の ~/.ssh/authorized_keys に追記する。

cat ~/.ssh/id_ed25519.pub

秘密鍵は他人に渡してはならない。秘密鍵が漏えいした場合、その鍵を登録しているサーバへ不正ログインされる可能性がある。秘密鍵にはパスフレーズを設定し、端末のディスク暗号化や権限設定と組み合わせて保護する必要がある。

`known_hosts` とホスト鍵の重要性

SSHでは、ユーザーの鍵だけでなく、接続先サーバを識別するためのホスト鍵も使われる。初回接続時に表示されるフィンガープリントは、接続先が本当に意図したサーバか確認するための情報である。

初回接続時に次のような表示が出ることがある。

The authenticity of host 'example.com' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting?

ここで何も確認せず yes と入力すると、中間者攻撃を見逃す可能性がある。特に本番サーバ、踏み台サーバ、社内基盤では、クラウド管理画面、構成管理ツール、管理者から共有された正規のフィンガープリントと照合する必要がある。

接続先のホスト鍵が変わった場合、SSHクライアントは警告を出す。サーバ再構築やIPアドレス再利用でも発生するが、攻撃の可能性もあるため、原因を確認してから known_hosts を更新するべきである。

サーバ側設定の基本

SSHサーバの主要な設定ファイルは、多くのUnix系環境で /etc/ssh/sshd_config である。OpenSSHの sshd_config マニュアルでは、sshd がこのファイルから設定を読み込むと説明されている。(OpenBSD Manual Pages)

基本的な設定例は次の通りである。

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AllowUsers deploy admin
ClientAliveInterval 300
ClientAliveCountMax 2

各項目の意味は次の通りである。

設定	目的
`PermitRootLogin no`	rootユーザーでの直接ログインを禁止する
`PubkeyAuthentication yes`	公開鍵認証を有効にする
`PasswordAuthentication no`	パスワード認証を無効にする
`AllowUsers`	ログイン可能なユーザーを限定する
`ClientAliveInterval`	応答確認の間隔を指定する
`ClientAliveCountMax`	応答がない場合の切断条件を指定する

ただし、PasswordAuthentication no は公開鍵で確実にログインできることを確認してから設定する必要がある。設定変更後は、既存のSSHセッションを閉じる前に別ターミナルで新規ログインを試す。ログイン不能になると、クラウドのシリアルコンソールや物理コンソールが必要になる場合がある。

設定変更後は構文確認を行う。

sudo sshd -t

問題がなければSSHサーバを再読み込みまたは再起動する。

sudo systemctl reload sshd

ディストリビューションによってサービス名が ssh の場合もある。

sudo systemctl reload ssh

ポート番号変更の効果と限界

SSHの待ち受けポートを22番から別の番号へ変える運用はよくある。これはインターネット上の自動スキャンや総当たり試行を減らす効果がある。

しかし、ポート番号変更は本質的な認証強化ではない。攻撃者がポートスキャンを行えば、SSHが動作しているポートは発見され得る。したがって、ポート変更だけで安全になったと考えるのは誤りである。

実務では、次の対策を組み合わせる。

公開鍵認証を使う
パスワード認証を無効にする
rootログインを禁止する
ログイン可能ユーザーを絞る
ファイアウォールやセキュリティグループで接続元を制限する
ログ監視を行う
必要に応じて多要素認証を導入する

ポートフォワーディング

SSHの便利な機能にポートフォワーディングがある。これはSSH接続を通じて別の通信を転送する仕組みである。

ローカルポートフォワーディングの例は次の通りである。

ssh -L 15432:localhost:5432 user@app-server

この例では、手元の localhost:15432 への接続が、SSH接続先から見た localhost:5432 へ転送される。リモートサーバ上のPostgreSQLへ安全に接続したい場合などに使える。

一方、リモートポートフォワーディングは次の形式である。

ssh -R 18080:localhost:8080 user@app-server

これは接続先サーバ側のポートを、手元の環境へ転送する。開発環境の一時公開や内部検証に使われることがある。

ただし、ポートフォワーディングは便利である反面、ネットワーク境界を迂回する経路にもなる。サーバ用途によっては、AllowTcpForwarding no や DisableForwarding yes を検討する必要がある。OpenSSHの sshd_config では、TCP転送や各種転送機能を制御する設定が定義されている。(OpenBSD Manual Pages)

`ssh-agent` の使いどころ

ssh-agent は、秘密鍵の復号結果を一時的に保持し、SSH接続時に毎回パスフレーズを入力しなくて済むようにする仕組みである。OpenSSHのマニュアルでも、ssh-agent は秘密鍵を保持する認証エージェントとして扱われている。(OpenSSH)

鍵を追加する例は次の通りである。

ssh-add ~/.ssh/id_ed25519

登録済みの鍵を確認する。

ssh-add -l

ssh-agent は便利だが、エージェント転送には注意が必要である。

ssh -A [email protected]

-A はエージェント転送を有効にする。踏み台サーバ経由でさらに別のサーバへ接続する場合に便利だが、踏み台サーバが侵害されていると、エージェントを悪用される危険がある。必要な接続だけに限定し、恒久的に ForwardAgent yes を設定する運用は避けるべきである。

よくある誤解

SSHは暗号化されているため設定不要という誤解

SSHは通信を暗号化するが、設定が安全であるとは限らない。弱いパスワード、共有アカウント、漏えいした秘密鍵、広すぎるログイン許可があれば、不正ログインの原因になる。

ポートを変えれば安全という誤解

ポート変更はノイズ削減には役立つが、認証強化ではない。根本的な対策は、鍵認証、接続元制限、ログ監視、権限分離である。

公開鍵は秘密にすべきという誤解

公開鍵は公開してもよい前提の情報である。ただし、どの公開鍵をどのアカウントに登録するかは認可に関わるため、管理は必要である。秘密にすべきなのは秘密鍵である。

`known_hosts` の警告は削除すればよいという誤解

ホスト鍵の警告は、接続先の同一性が変わったことを示す重要な警告である。再構築など正当な理由がある場合もあるが、確認せず削除する運用は危険である。

実務での安全な運用チェックリスト

SSHを安全に運用するには、次の項目を確認する。

個人ごとにユーザーアカウントを分ける
共有アカウントを避ける
公開鍵認証を基本にする
秘密鍵にパスフレーズを設定する
不要になった公開鍵を authorized_keys から削除する
root直接ログインを禁止する
パスワード認証を無効化する前に鍵ログインを検証する
接続元IPアドレスを制限する
AllowUsers や AllowGroups でログイン対象を限定する
エージェント転送を必要最小限にする
ポートフォワーディングを用途に応じて制限する
auth.log や secure などの認証ログを監視する
OpenSSHとOSパッケージを定期的に更新する

まとめ

SSHは、サーバ管理に不可欠な基盤技術である。安全性の中心は、通信の暗号化だけでなく、接続先の検証、ユーザー認証、鍵管理、サーバ側の権限制御にある。

実務では、公開鍵認証を基本とし、秘密鍵を厳重に保護し、sshd_config でログイン経路を絞る。さらに、known_hosts の警告を軽視せず、ポートフォワーディングやエージェント転送のような便利な機能もリスクを理解して使う必要がある。

SSHは単純なコマンドに見えるが、実際には認証、暗号、ネットワーク、運用管理が交差する重要な仕組みである。基本を理解して設定することが、サーバ運用の安全性を大きく左右する。

結論