セキュアなSSHサーバの構築と運用ガイド（Ubuntu 上）

【概要】 Ubuntu上でのセキュアなSSHサーバ構築はsshd_config設定と公開鍵認証で行う。ufwとFail2Banで防御し、パスワード認証は無効にする。Ubuntu 24.04ではsshd.socket再起動が必要である。ログ確認やデバッグ、緊急復旧の方法がある。

SSH サーバの設定（SSH サーバは Ubuntu マシン）

1. OpenSSHのインストール

SSH接続を行うクライアント機能と、接続を受け付けるサーバ機能の両方をインストールする。サーバ機自身が他のSSHサーバへ接続する可能性も考慮し、クライアントもインストールしておくと便利である。

1.1. パッケージリストの更新

# パッケージリストの情報を更新
sudo apt update

1.2. OpenSSH クライアントのインストール

sudo apt -y install openssh-client

1.3. OpenSSH サーバのインストール

sudo apt -y install openssh-server

2. SSHサーバ設定ファイル (`/etc/ssh/sshd_config`) の編集

SSHサーバの挙動を制御する主要な設定ファイル `/etc/ssh/sshd_config` を編集する。編集後はSSHサーバの再起動が必要である。この操作は、接続先（SSH サーバ側）のマシンで、システム管理者が実施する必要がある。

基本的なセキュリティ設定:

ログ設定:

（オプション）ポート番号の変更:

アクセス制御:

3. 公開鍵認証の有効化

パスワード認証よりも安全な公開鍵認証を有効にする。

以下の操作は，接続先（SSH サーバ側）のマシンで，システム管理者が実施する．

/etc/ssh/sshd_config を編集する。

設定変更後、SSHサーバを再起動して設定を反映させる。

# systemd を使用する最近の Ubuntu の場合 (推奨)
# Ubuntu 24.04 LTS ではソケットアクティベーションを使用しているため、ssh.socketを再起動する
sudo systemctl restart ssh.socket

4. 接続ログの確認

SSHサーバへの接続試行や認証の成功・失敗に関するログは、通常 `/var/log/auth.log` に記録される。不審なアクセスがないか、設定が正しく反映されているかを確認するために、定期的にログを確認することが重要である。ログには、成功/失敗したログイン試行、使用された認証方法、接続元IPアドレスなどの情報が含まれる。

SSHログは`/var/log/auth.log`でモニタリング可能であり、tail -f /var/log/auth.logで不正アクセスの試みをリアルタイムで監視できる。

# ログ全体を表示
cat /var/log/auth.log

# "ssh" を含む行をフィルタリングして表示 (より関連性の高いログのみ)
grep sshd /var/log/auth.log

# リアルタイムでログを監視
tail -f /var/log/auth.log

SSH サーバの再起動（Ubuntu の場合）

Ubuntu では，次のコマンドで SSH サーバを再起動する．設定ファイルの書き換えを行った場合には， 再起動の後の動作確認を忘れないこと．Ubuntu 24.04 LTSではOpenSSHはデフォルトでsystemdソケットアクティベーションを使用しており、接続要求があるまでsshdが起動しないため、メモリ使用量を節約できる。設定変更後、sudo systemctl restart ssh.socketコマンドで変更を適用する必要がある。 

# systemd を使用する最近の Ubuntu の場合 (推奨)
sudo systemctl restart ssh.socket

5. TCP Wrapper による IP アドレス制限 (注意点あり)

注意: TCP Wrapper (`/etc/hosts.allow`, `/etc/hosts.deny`) は、SSHサーバへのアクセス元 IP アドレスを制限する古典的な方法である。しかし、Ubuntu 24.04 LTSのOpenSSHではTCP Wrapperのサポートが廃止されたため、この手順は無効である。代わりにufwなどのファイアウォールでアクセス制御を行う必要がある。可能な限り、後述するファイアウォール (`ufw` など) を使用して IP アドレス制限を行うことを強く推奨する。

もし、利用している環境がUbuntu 24.04 LTS以前など、システムが TCP Wrapper をサポートしており、これを使用する場合は、以下の設定を行う。（システム管理者権限で実施）

設定ファイル編集後は、通常サービスの再起動は不要である。反映されない場合は試してみる。

6. ファイアウォール (`ufw`) によるアクセス制御

`ufw` (Uncomplicated Firewall) は、Ubuntu で標準的に利用可能なファイアウォール管理ツールである。不要なポートを閉じ、SSH アクセスを許可するポート（デフォルトは 22 番）のみを開けることで、セキュリティを強化する。

Ubuntu 24.04ではufwの設定でsudo ufw allow sshとsudo ufw enableを実行することで、SSHポートのみを許可するシンプルなファイアウォール設定が可能である。

基本的な設定手順: (システム管理者権限で実施)

  1. ufw の有効化: 
    sudo ufw enable

    (有効化すると、既存の接続が切断される可能性があるため注意が必要である)

  2. デフォルトポリシーの設定 (重要):
    • 受信 (Incoming) をすべて拒否: 
      sudo ufw default deny incoming
    • 送信 (Outgoing) をすべて許可 (一般的): 
      sudo ufw default allow outgoing

    (デフォルトで受信を拒否することで、許可した通信以外はすべて遮断される)

  3. SSH ポートの許可:
    • デフォルトの SSH ポート (22) を許可: 
      sudo ufw allow ssh

      (これは sudo ufw allow 22/tcp と同等である)

    • もし sshd_config でポート番号を変更した場合 (例: 2222): 
      sudo ufw allow 2222/tcp
  4. (オプション) 他に必要なポートの許可:
    • Web サーバを運用している場合など: 
      sudo ufw allow http  # ポート 80
sudo ufw allow https # ポート 443
  5. (推奨) SSH ブルートフォース攻撃対策: 
    sudo ufw limit ssh
    • 説明: 短時間に多数の接続試行があった場合に、その送信元からの接続を一時的に拒否する。ufw allow ssh の代わりに、または追加で設定することで、パスワード総当たり攻撃などを緩和できる。UFWでSSHポートを制限する際にはsudo ufw limit sshコマンドを使用すると、ブルートフォース攻撃を効果的に防止できる。
  6. 設定状態の確認: 
    sudo ufw status verbose

これらの設定により、許可されたポート以外へのアクセスは拒否され、SSH ポートへの不正アクセス試行も制限される。

7. Fail2Ban による不正アクセス試行の自動検知・防御

Fail2Ban は、サーバのログファイル（例: `/var/log/auth.log`）を監視し、不正アクセス試行（例: パスワード総当たり攻撃）を検知すると、その送信元 IP アドレスからのアクセスを一定期間自動的にファイアウォールでブロックするツールである。Fail2banはSSHに対するブルートフォース攻撃を自動検知・ブロックする強力なツールで、Ubuntu 24.04でもsudo apt install fail2banで簡単に導入できる。

以下の操作は，接続先（SSH サーバ側）のマシンで，システム管理者が実施する．

インストールと設定: (システム管理者権限で実施)

  1. Fail2Ban のインストール: 
    # パッケージリストの情報を更新
sudo apt update
sudo apt -y install fail2ban

    (インストール後、デフォルトで sshd 用の監視 (jail) が有効になることが多い)

  2. sshd 監視状況の確認: 
    sudo fail2ban-client status sshd

    (sshd jail が有効になっていれば、基本的な設定は完了している)

  3. (オプション) カスタム ブラックリストフィルタの導入:
    • 記事で紹介されている方法は、公開されているブラックリストルールを導入する高度な設定である。
    • 注意: GitHub の `master` ブランチから直接ファイルをダウンロードする方法は、将来的に内容が変更される可能性がある。安定した運用のためには、リリースタグなどを確認するか、プロジェクトのドキュメントに従うことを推奨する。

      元の記事にある公開情報: https://github.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning

    • 手順 (記事記載の例): 
      # フィルタ定義ファイルのダウンロード
sudo wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/filter.d/blacklist.conf -O /etc/fail2ban/filter.d/blacklist.conf
# アクション定義ファイルのダウンロード
sudo wget https://raw.githubusercontent.com/mitchellkrogza/Fail2Ban-Blacklist-JAIL-for-Repeat-Offenders-with-Perma-Extended-Banning/master/action.d/blacklist.conf -O /etc/fail2ban/action.d/blacklist.conf
  4. (オプション) カスタム jail の設定 (`jail.local`):
    • `jail.conf` を直接編集せず、設定の上書きや追加は `/etc/fail2ban/jail.local` に記述する。ファイルが存在しない場合は新規作成する。
    • 記事記載の例: 
      [DEFAULT]
# デフォルト設定 (この例では port と filter を指定しているが、通常 DEFAULT セクションでの filter 指定は特殊)
# port = 0:65535 # 監視対象ポート (通常は jail ごとに指定)
# filter = %(__name__)s # フィルタ名 (通常は jail ごとに指定)

[blacklist]
enabled   = true                # この jail を有効にするか
logpath   = /var/log/fail2ban.* # 監視するログファイル (注意: これは fail2ban 自身のログであり、通常は auth.log などを監視対象とする jail を定義する)
filter    = blacklist           # 使用するフィルタ定義 (上記でダウンロードしたもの)
banaction = blacklist           # BAN 時に実行するアクション (上記でダウンロードしたもの)
action    = %(action_)s          # BAN アクションの詳細 (通常は %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]) のような形式
bantime   = 31536000          # BAN する期間 (秒単位, ここでは 1 年)
findtime  = 31536000          # 試行をカウントする期間 (秒単位, ここでは 1 年)
maxretry  = 10                  # findtime 内に許容する最大試行回数
    • 補足: 上記の `[blacklist]` jail の設定は、`fail2ban` 自身のログを監視して、特定のパターン（おそらく他の jail によって BAN された IP）をさらに長期間 BAN する、という非常に高度で特殊な使い方のように見える。SSH の不正ログインを直接防ぐ標準的な設定 (`[sshd]` jail) とは異なる可能性が非常に高い。一般的なSSH不正ログイン対策としては、標準的な `/var/log/auth.log` を監視する `[sshd]` jail の設定を使用することが強く推奨される。標準的な `[sshd]` jail の設定は `/etc/fail2ban/jail.conf` を参照し、必要に応じて `jail.local` で上書きする必要がある (例: `bantime` の変更など)。
  5. (オプション) ブラックリストファイルの準備: 
    sudo touch /etc/fail2ban/ip.blacklist
sudo chmod 644 /etc/fail2ban/ip.blacklist # 権限はより制限的で良い場合が多い
  6. Fail2Ban サービスのリロード/再起動:
    • 設定ファイルを再読み込み: 
      sudo fail2ban-client reload
    • サービスを再起動 (設定変更が大きい場合): 
      sudo systemctl restart fail2ban
    • (必要であれば) SSH サービスも再起動: 
      sudo systemctl restart ssh.socket # Ubuntu 24.04 LTS の場合
sudo systemctl restart ssh # それ以外の systemd 環境の場合
  7. ログとブロック状況の確認: 
    # Fail2Ban のログを確認
sudo cat /var/log/fail2ban.log

# 現在 BAN されている IP を確認 (sshd jail の場合)
sudo fail2ban-client status sshd

# (カスタム設定の場合) ブラックリストファイルの内容を確認
# cat /etc/fail2ban/ip.blacklist

II. クライアント側の設定: 公開鍵認証の準備

パスワード認証の代わりに、より安全な公開鍵認証を利用するための設定をクライアントマシン（接続元の PC）で行う。

8. 公開鍵認証の仕組みとキーペア

公開鍵認証では、「秘密鍵」と「公開鍵」のペアを使用する。

ログイン時、サーバは公開鍵を使ってクライアントに「チャレンジ」を送り、クライアントは秘密鍵を使ってそれに正しく応答することで認証が行われる。パスワードのようにネットワーク上を流れないため、盗聴のリスクが低く、ブルートフォース攻撃も困難である。

このセクションでは、キーペアを生成し、公開鍵をサーバへ登録する手順を説明する。

9. キーペアの生成 (クライアントマシンでの操作)

安全で高速な Ed25519 形式のキーペアを生成することを推奨する（強度が高く、処理速度も速いため）。Ubuntu 24.04でもEd25519鍵が推奨されており、ssh-keygen -t ed25519 -C "your_email@example.com"コマンドでより安全な鍵を生成できる。

以下の操作は，接続元（ユーザマシン）で，各ユーザが行う．SSHキーは個人単位で発行し、共有せず、定期的なローテーション（年に1回程度）を行うことがベストプラクティスである。

9.1. Windows の場合 (MobaXterm を使用)

  1. MobaXterm のインストール

    【サイト内の関連ページ】

    • Windows での MobaXterm のインストール: 別ページ »で説明
    • Windows でのリモート接続，ファイル転送ソフト MobaXterm Personal 版のインストール（winget を使用しない）と利用: 別ページ »で説明

    Windows マシン の場合は，MobaXTermをインストールし，それに内蔵の ssh-keygen, ssh を使うのが便利である．

  2. MobaXterm の起動とターミナル操作:

    MobaXterm を起動し、ローカルターミナルを開く。(通常、ユーザのプロファイル内に鍵を保存するため管理者権限は不要である。環境によっては管理者権限が必要な場合もある。)

    Windows のコマンドプロンプトを管理者として実行するには， 検索窓で「cmd」と入れたあと， 右クリックメニューで「管理者として実行」を選ぶのが簡単である．

    Windows 検索窓でcmdを入力して管理者として実行を選択する画面例
  3. キーペア生成コマンドの実行:

    「ssh-keygen」を使う。公開鍵は，接続先（SSH サーバ側）の所定のファイルに追加して使う。

    ターミナルで次を実行する。

    ssh-keygen -t ed25519 -C "your_email@example.com"
    • -t ed25519: キータイプとして Ed25519 を指定する。
    • -C "コメント": 鍵の識別用コメント。通常はメールアドレスなどを入れるが、空でも構わない (-C '')。
  4. 保存場所の指定:

    Enter file in which to save the key (/home/mobaxterm/.ssh/id_ed25519):

    通常は Enter キーを押してデフォルトの場所 (%USERPROFILE%\Documents\MobaXterm\home\.ssh\id_ed25519 など) に保存する。

  5. パスフレーズの設定 (重要):

    Enter passphrase (empty for no passphrase):

    秘密鍵を保護するためのパスフレーズを入力する。パスフレーズを設定することを強く推奨する。 これにより、万が一秘密鍵ファイルが盗まれても、パスフレーズがなければ悪用できない。確認のため、同じパスフレーズを再入力する。入力中、画面には表示されない。

    ssh-keygenでのパスフレーズ入力画面
  6. 生成ファイルの確認:

    デフォルトの場所に id_ed25519 (秘密鍵) と id_ed25519.pub (公開鍵) の2つのファイルが生成されたことを確認する。

    cd /d c:%HOMEPATH%\Documents\MobaXterm\home\.ssh
dir /w
    Windowsで生成された鍵ファイル一覧の表示
  7. (参考) MobaXterm のデフォルト設定について:

    「キーペアのファイルを MobaXterm の配下にコピーする」手順は、ssh-keygen を MobaXterm 外で実行した場合や、特定の場所に鍵を置きたい場合の手順である。MobaXterm 内のローカルターミナルで生成した場合、通常は適切な場所（上記デフォルトの場所）に直接保存されるため、このコピー手順は不要である。

    ＜Documents のフォルダ＞\MobaXterm\home\.ssh に id_ed25519, id_ed25519.pub をコピーする

    MobaXterm フォルダ構造例
  8. (参考) FileZilla での利用:

    FileZillaなどの PuTTY ベースのツールを使うときは、生成した秘密鍵ファイル (`id_ed25519`) を設定する必要がある。FileZilla は PuTTY 形式の鍵 (.ppk) を要求するため、初回設定時に OpenSSH 形式の秘密鍵を .ppk 形式に変換するかどうか尋ねられる。「はい」を選択すると変換が行われる。

    SFTP, 「鍵ファイル」，鍵ファイルとして先ほど生成した id_ed25519 を設定する．

    設定すると，「対応していません。ファイルを変換しますか？」のように表示される． ここで，「はい」を選ぶ． ppk ファイルへの変換が自動で行われ，次のように表示される．

    FileZillaでの鍵ファイル変換プロンプト

9.2. Ubuntu (または他の Linux/macOS) の場合

  1. ターミナルを開く:
  2. キーペア生成コマンドの実行:

    「ssh-keygen」を使う。公開鍵は，接続先（SSH サーバ側）の所定のファイルに追加して使う。

    ssh-keygen -t ed25519 -C "your_email@example.com"
  3. 保存場所の指定:

    Enter file in which to save the key (/home/your_username/.ssh/id_ed25519):

    通常は Enter キーを押してデフォルトの場所 ($HOME/.ssh/id_ed25519) に保存する。

  4. パスフレーズの設定 (重要):

    Windows の場合と同様に、秘密鍵を保護するためのパスフレーズを設定することを強く推奨する。確認のため、同じパスフレーズを再入力する。入力中、画面には表示されない。

    ssh-keygenでのパスフレーズ入力画面(Linux)
  5. 生成ファイルの確認:

    $HOME/.ssh/ ディレクトリに id_ed25519 (秘密鍵) と id_ed25519.pub (公開鍵) が生成されたことを確認する。

    cd $HOME/.ssh
ls
    Linuxで生成された鍵ファイル一覧の表示

10. 公開鍵のサーバへの登録 (クライアントマシンから操作)

生成した公開鍵 (`id_ed25519.pub`) の内容を、接続先 SSH サーバの `~/.ssh/authorized_keys` ファイルに追記する必要がある。

10.1. 推奨方法: `ssh-copy-id` コマンド (利用可能な場合)

`ssh-copy-id` は公開鍵をサーバに簡単かつ安全にコピーするための専用コマンドである。Linux, macOS, MobaXterm, Git Bash などで利用可能である。

ssh-copy-id -i ~/.ssh/id_ed25519.pub ユーザー名@接続先サーバアドレス

実行すると、サーバのパスワード (まだパスワード認証が無効になっていない場合) または既存の鍵のパスフレーズを求められる。認証に成功すると、公開鍵がサーバの `~/.ssh/authorized_keys` に適切に追加される。

10.2. 代替方法: 手動コピー

`ssh-copy-id` が使えない場合、手動で公開鍵の内容をコピーする。

Windows (MobaXterm/コマンドプロンプト):

「mkdir -p ~/.ssh」は .ssh ディレクトリを作るためのもの (存在しない場合)。パーミッション設定も同時に行う。 

:: 公開鍵の内容をクリップボードにコピーするか、以下のコマンドでパイプする
type %USERPROFILE%\Documents\MobaXterm\home\.ssh\id_ed25519.pub | ssh ユーザー名@接続先サーバアドレス "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
:: 実行後、接続先サーバのパスワードを求められる
Windowsからの手動コピーコマンド実行例

Ubuntu (または他の Linux/macOS):

「mkdir -p ~/.ssh」は .ssh ディレクトリを作るためのもの (存在しない場合)。パーミッション設定も同時に行う。 

# 公開鍵の内容をサーバに追記するコマンド
cat ~/.ssh/id_ed25519.pub | ssh ユーザー名@接続先サーバアドレス "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
# 実行後、接続先サーバのパスワードを求められる
Linuxからの手動コピーコマンド実行例

11. 公開鍵認証でのログイン試行

公開鍵をサーバに登録したら、実際にログインできるか試す。

ssh ユーザー名@接続先サーバアドレス

今度はサーバのパスワードではなく、キーペア生成時に設定したパスフレーズを求められるはずである (Enter passphrase for key ...)。正しくパスフレーズを入力してログインできれば、公開鍵認証の設定は成功である。

公開鍵認証でのログイン時のパスフレーズ入力画面 (Windows)
公開鍵認証でのログイン時のパスフレーズ入力画面 (Ubuntu)

(MobaXterm や他の GUI クライアントを使用している場合は、接続設定で秘密鍵ファイル (例: id_ed25519) を指定する必要があるかもしれない。)

(FileZilla など PuTTY ベースのツールで SFTP 接続する場合、Ed25519 秘密鍵を PuTTY 形式 (.ppk) に変換する必要がある場合がある。ツールの指示に従う。)

(補足) SSHエージェントの利用

秘密鍵にパスフレーズを設定した場合、接続ごとにパスフレーズの入力が必要となる。これを省略するためには、SSHエージェントを利用する方法がある。SSHエージェントを活用することで、セキュリティを維持しながら再入力の手間を省くことができる。

SSHエージェントは秘密鍵をメモリ上に保持し、認証時に自動でパスフレーズを入力する。多くのSSHクライアントに付属しており、一度秘密鍵をエージェントに登録すれば、ターミナルを閉じたりシステムを再起動するまでパスフレーズの入力が不要となる。MobaXtermや標準的なLinux/macOS環境でも利用可能である。

(秘密鍵のパスフレーズを変更するにはssh-keygen -p -f ~/.ssh/id_ed25519コマンドを使用する)

III. 最終的なセキュリティ強化

12. パスワード認証の無効化 (重要)

公開鍵認証でのログインが確実に機能することを確認したら、セキュリティを最大限に高めるために、従来のパスワード認証を無効にする。これにより、パスワードを知っていても SSH ログインはできなくなり、ブルートフォース攻撃のリスクが大幅に減少する。

警告: この設定を行う前に、必ず公開鍵認証でログインできることをテストする必要がある。 もし公開鍵認証に失敗していてパスワード認証を無効にすると、SSH でサーバにログインできなくなる可能性がある。パスワード認証を完全に無効化するのがベストプラクティスである。

以下の操作は，接続先（SSH サーバ側）のマシンで，システム管理者が実施する．

  1. /etc/ssh/sshd_config を編集する。 
    PasswordAuthentication no
    • この行がコメントアウトされているか yes になっている場合は、no に変更する。
    PasswordAuthentication no の設定例
  2. SSH サーバを再起動して設定を反映させる。 
    # systemd を使用する最近の Ubuntu の場合 (推奨)
# Ubuntu 24.04 LTS ではソケットアクティベーションを使用しているため、ssh.socketを再起動する必要がある。
sudo systemctl restart ssh.socket

    Ubuntu 24.04ではOpenSSHはデフォルトでsystemdソケットアクティベーションを使用しており、接続要求があるまでsshdが起動しないため、メモリ使用量を節約できる。設定変更後、sudo systemctl restart ssh.socketコマンドで変更を適用する必要がある。

これ以降、パスワードによる SSH ログインは拒否され、有効な秘密鍵を持つクライアントのみが (パスフレーズ入力後に) ログインできるようになる。

IV. トラブルシューティング

SSH 接続で問題が発生した場合の基本的な切り分け手順である。

13. サーバ側でのデバッグ

SSH サーバの動作状況を詳細に確認するには、現在動作中の SSH サービスを停止し、デバッグモードで手動起動する。

(SSH接続の詳細ログを取得するには、`/etc/ssh/sshd_config`でLogLevel VERBOSEまたはLogLevel DEBUGに設定する方法もある)

  1. 既存の SSH サービスを停止: 
    sudo systemctl stop ssh.socket # Ubuntu 24.04 LTS の場合
sudo systemctl stop ssh # それ以外の systemd 環境の場合
  2. デバッグモードで SSH サーバを起動: 
    sudo /usr/sbin/sshd -d -p <ポート番号>
    • -d: デバッグモードを有効にする。接続試行の詳細なログがコンソールに出力される。
    • -p <ポート番号>: SSH サーバが待ち受けるポート番号を指定する。デフォルト (22) 以外を使用している場合は指定が必要である。

    (このプロセスはフォアグラウンドで実行されるため、Ctrl+C で停止できる。確認が終わったら、sudo systemctl start ssh.socket または sudo systemctl start ssh などでサービスを再開する必要がある)

    サーバ側でのSSHデバッグモードはsudo sshd -d -p ポート番号で実行できることを覚えておく。

14. クライアント側でのデバッグ

接続元クライアントから接続を試みる際に、詳細な情報を表示させることで問題の原因特定に役立つ。

ssh -v ユーザー名@接続先サーバアドレス

SSHのデバッグにssh -vまたは-vv、-vvvオプションを使用すると、接続問題のトラブルシューティングに役立つ。

サーバ側とクライアント側のデバッグ情報を組み合わせることで、設定ミス、鍵の不一致、パーミッションの問題、ファイアウォールによるブロックなど、多くの問題の原因を特定できる。

(補足) 緊急時のSSH接続復旧

ファイアウォール設定ミスやsshd_configの誤りなどにより、SSH接続が完全にできなくなった場合、以下の方法で復旧を試みる。

【サイト内の関連ページ】