SSH鍵認証の設定|パスワードログインを無効化

SSH鍵認証の設定|パスワードログインを無効化する完全ガイド
SSHサーバーへのセキュアなアクセスを実現するなら、パスワード認証を無効化してSSH鍵認証を必須化してください。公開鍵暗号方式を活用したSSH鍵認証は、総当たり攻撃に対する耐性が高く、サーバーの安全性を飛躍的に向上させます。本記事では、LinuxサーバーにおけるSSH鍵認証の設定方法から、パスワードログインの完全無効化手順、さらには運用時のベストプラクティスまで、実務で即座に活用できる具体的な手順を網羅的に解説します。SSHセキュリティの強化を検討中のシステム管理者やDevOpsエンジニアは必見です。
目次
1. はじめに:SSH鍵認証の重要性
SSH(Secure Shell)は、リモートサーバーへの安全なアクセスを提供するプロトコルですが、従来のパスワード認証には重大なセキュリティリスクが存在します。具体的には、総当たり攻撃(ブルートフォースアタック)や辞書攻撃によるパスワードクラッキングの脅威です。総当たり攻撃の成功率は、パスワードの複雑さに依存しますが、一般的な8文字のパスワードであっても、現代のコンピュータでは数時間から数日で解読される可能性があります(出典: NIST Special Publication 800-63B)。
これに対して、SSH鍵認証は公開鍵暗号方式を採用しており、以下のような優れたセキュリティ特性を持ちます。
- 耐ブルートフォース性:鍵の長さ(一般的に2048ビット以上)により、総当たり攻撃が事実上不可能
- 二要素認証の実現:鍵の所有(物理的な鍵ファイル)と知識(鍵パスフレーズ)の組み合わせ
- 自動化と運用効率:スクリプトやCI/CDパイプラインでの安全な認証が可能
- 監査ログの向上:鍵ベースの認証はログに記録されやすく、不正アクセスの検知が容易
実際に、2023年のサイバーセキュリティ統計によると、SSH鍵認証を導入した企業では、リモートアクセスに関連するセキュリティインシデントが73%減少した(出典: Verizon Data Breach Investigations Report 2023)。これは、鍵認証がパスワード認証に比べて圧倒的に安全であることを示す明確な証拠です。
本記事では、Linuxサーバー(主にUbuntu、CentOS、RHEL)を対象に、SSH鍵認証の設定からパスワードログインの完全無効化まで、実務で即座に適用できる手順を解説します。また、運用時のベストプラクティスやトラブルシューティングについても詳しく取り上げます。
2. SSH鍵ペアの生成と配布
SSH鍵認証を導入するには、まずクライアント側でSSH鍵ペアを生成する必要があります。鍵ペアは、秘密鍵(private key)と公開鍵(public key)の2つで構成され、秘密鍵はクライアント側で厳重に管理し、公開鍵はサーバー側に配置します。
2-1. 鍵ペアの生成手順
以下のコマンドを実行して、SSH鍵ペアを生成します。ここでは、一般的なRSA鍵(2048ビット)を例に解説します。
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"このコマンドのオプションは以下の通りです。
| オプション | 説明 |
|---|---|
-t rsa | 鍵の種類を指定(rsa、ecdsa、ed25519など) |
-b 4096 | 鍵のビット長を指定(推奨値は4096ビット) |
-C "your_email@example.com" | コメント(任意のテキスト)を追加 |
実行すると、以下のようなプロンプトが表示されます。
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):デフォルトの保存場所(~/.ssh/id_rsa)を使用する場合はEnterキーを押します。異なる場所に保存したい場合は、フルパスを指定します。
次に、鍵ファイルにパスフレーズ(任意のパスワード)を設定します。パスフレーズは、秘密鍵の追加のセキュリティレイヤーとして機能します。以下のプロンプトが表示されます。
Enter passphrase (empty for no passphrase):Enter same passphrase again:パスフレーズは必須ではありませんが、セキュリティを向上させるために設定することを強く推奨します。パスフレーズを設定すると、鍵を使用する際に毎回パスフレーズの入力が求められますが、これは鍵の紛失や不正使用を防ぐ重要な対策です。
2-2. 生成された鍵ファ…
鍵ペアの生成が完了すると、~/.ssh/ディレクトリに以下の2つのファイルが作成されます。
id_rsa:秘密鍵(絶対に他者に漏らしてはいけません)id_rsa.pub:公開鍵(サーバー側に配置するファイル)
ファイルのパーミッションを確認し、秘密鍵が適切に保護されていることを確認します。
$ ls -la ~/.ssh/total 8
drwx------ 2 username username 4096 Jan 10 12:34 .
drwxr-xr-x 33 username username 4096 Jan 10 12:34 ..
-rw------- 1 username username 3389 Jan 10 12:34 id_rsa
-rw-r--r-- 1 username username 745 Jan 10 12:34 id_rsa.pub秘密鍵(id_rsa)のパーミッションは600(所有者のみ読み書き可)である必要があります。公開鍵(id_rsa.pub)は644(所有者読み書き、グループ・他者読み取り可)で問題ありません。
2-3. 公開鍵の配布方法
生成した公開鍵(id_rsa.pub)をサーバー側に配置する必要があります。主な配布方法は以下の通りです。
方法1:ssh-copy-idコマンドを使用する(推奨)
ssh-copy-idコマンドは、公開鍵をリモートサーバーに自動的にコピーして、~/.ssh/authorized_keysファイルに追加する便利なツールです。
$ ssh-copy-id -i ~/.ssh/id_rsa.pub username@server_ipこのコマンドを実行すると、以下の処理が行われます。
- サーバーへのSSH接続(パスワード認証)
- 公開鍵の
~/.ssh/authorized_keysへの追加 - 必要なディレクトリとファイルのパーミッション設定
注意事項:ssh-copy-idを使用するには、サーバーへのパスワード認証が有効である必要があります。そのため、一時的にパスワード認証を有効にしておく必要があります。
方法2:手動で公開鍵を配置する
ssh-copy-idが使用できない場合は、手動で公開鍵を配置します。以下の手順で実施します。
- 公開鍵ファイルの内容を表示します。
$ cat ~/.ssh/id_rsa.pub出力例:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC8... your_email@example.com- サーバーにSSH接続します。
$ ssh username@server_ip~/.sshディレクトリを作成します(存在しない場合)。
$ mkdir -p ~/.ssh$ chmod 700 ~/.sshauthorized_keysファイルに公開鍵を追加します。
$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC8... your_email@example.com" >> ~/.ssh/authorized_keys$ chmod 600 ~/.ssh/authorized_keys以上で、公開鍵の配布は完了です。次に、サーバー側のSSH設定を変更して、鍵認証を有効化します。
3. サーバー側でのSSH鍵認証設定
サーバー側では、SSHデーモン(sshd)の設定ファイルを編集して、SSH鍵認証を有効化します。また、パスワード認証を無効化する設定も行います。
3-1. SSHデーモンの…
SSHデーモンの設定ファイルは、主に以下の場所に存在します。
- Ubuntu/Debian系:
/etc/ssh/sshd_config - CentOS/RHEL系:
/etc/ssh/sshd_config
設定ファイルを編集する前に、現在の設定を確認します。
$ sudo cat /etc/ssh/sshd_config主な設定項目は以下の通りです。
| 設定項目 | デフォルト値 | 推奨値 |
|---|---|---|
PubkeyAuthentication | yes | yes |
PasswordAuthentication | yes | no(鍵認証導入後) |
PermitRootLogin | prohibit-password(Ubuntu 22.04以降) | no(推奨) |
ChallengeResponseAuthentication | no | no |
UsePAM | yes | yes |
3-2. SSHデーモンの…
以下の手順で、SSHデーモンの設定を変更します。
- 設定ファイルをバックアップします。
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup- 設定ファイルを編集します。ここでは
nanoエディタを使用します。
$ sudo nano /etc/ssh/sshd_config以下の設定を変更または追加します。
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM yes注意事項:
PasswordAuthentication no:鍵認証を導入した後は、パスワード認証を無効化します。PermitRootLogin no:ルートログインを禁止します。代替として、一般ユーザーでログイン後にsudoを使用します。UsePAM yes:PAM(Pluggable Authentication Modules)を有効にします。これにより、鍵認証とパスワード認証の両方を柔軟に制御できます。
- 設定ファイルを保存してエディタを終了します。
- SSHデーモンを再起動して、設定を反映します。
$ sudo systemctl restart sshd重要:SSHデーモンを再起動する前に、必ず現在のSSH接続を維持した状態で設定をテストしてください。設定に誤りがあると、接続が切断され、サーバーへのアクセスができなくなる可能性があります。
3-3. SSH接続のテスト
設定変更後、新しいSSH接続を試みて、鍵認証が正常に動作することを確認します。
$ ssh username@server_ip鍵認証が正常に動作すれば、パスフレーズの入力を求められます。パスフレーズを入力すると、サーバーにログインできます。
万が一、接続に失敗した場合は、以下の手順でトラブルシューティングを行います。
- サーバー側のSSHログを確認します。
$ sudo tail -f /var/log/auth.logUbuntu/Debian系の場合は/var/log/auth.log、CentOS/RHEL系の場合は/var/log/secureを確認します。
- クライアント側のSSH接続ログを確認します。
$ ssh -v username@server_ip-vオプションを使用すると、詳細なログが表示され、接続の問題を特定しやすくなります。
4. クライアント側のSSH設定
クライアント側では、SSHクライアントの設定をカスタマイズして、鍵認証の利便性とセキュリティを向上させます。主な設定項目は、~/.ssh/configファイルを編集することで行います。
4-1. SSHクライアン…
~/.ssh/configファイルを作成または編集して、以下の設定を追加します。
Host server1
HostName 192.168.1.100
User username
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
Port 22
ServerAliveInterval 60
TCPKeepAlive yes各設定項目の説明は以下の通りです。
| 設定項目 | 説明 |
|---|---|
Host | 接続先サーバーのエイリアス(任意の名前) |
HostName | サーバーのIPアドレスまたはホスト名 |
User | SSH接続に使用するユーザー名 |
IdentityFile | 使用する秘密鍵ファイルのパス |
IdentitiesOnly | yesに設定すると、指定した鍵のみを使用して認証を行う |
Port | SSH接続に使用するポート番号(デフォルトは22) |
ServerAliveInterval | サーバーへのキープアライブパケットを送信する間隔(秒) |
TCPKeepAlive | yesに設定すると、TCP接続のキープアライブを有効化 |
注意事項:
~/.ssh/configファイルのパーミッションは600に設定します。- 複数のサーバーに接続する場合は、それぞれのサーバーに対して
Hostブロックを追加します。
4-2. SSHエージェン…
SSHエージェントは、秘密鍵のパスフレーズを一時的に保存して、頻繁なSSH接続時にパスフレーズの入力を省略できるツールです。以下の手順でSSHエージェントを設定します。
- SSHエージェントを起動します。
$ eval "$(ssh-agent -s)"出力例:
Agent pid 12345- 秘密鍵をSSHエージェントに追加します。
本記事はRoute Bloom編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。




