Access for Infrastructure で SSH する

Access for Infrastructure は、ユーザーが SSH サーバーへ接続する方法を細かく制御します。自己管理の SSH キー 方式と同様に、ユーザーデバイス上の Cloudflare One Client とサーバー上の Cloudflare Tunnel を使い、Cloudflare のネットワーク経由で安全なプライベート接続を作ります。Access for Infrastructure は、ターゲットごと・ユーザー名ごとの制御を持つアプリケーションレベルのポリシーと、SSH コマンドログを追加します。

Furthermore, Access for Infrastructure replaces 従来の SSH 鍵を、Access ログインで生成されたトークンに基づいてユーザーへ発行する短命証明書に置き換えます。従来の運用では、ユーザーが SSH 鍵ペアを生成し、管理者が公開鍵を各 SSH サーバーに配置してアクセスを許可します。これらの SSH 鍵は、サーバー上で数か月から数年にわたって変更されないことがあります。Cloudflare Access は SSH 鍵の管理負担をなくし、長期間有効な SSH 鍵を短命の SSH 証明書に置き換えることでセキュリティも向上します。

1. Cloudflare ダッシュボードで Networking > Tunnels を開きます。

   Tunnels を開く ↗

2. 新しいトンネルを作成する か、既存の cloudflared トンネルを編集します。

3. Cloudflare ダッシュボードで Networking > Routes を開きます。

   Routes を開く ↗

4. Create route > Tunnel CIDR を選択します。作成したトンネルを選び、サーバーの IP または CIDR アドレスを入力します（通常はプライベート IP ですが、パブリック IP も使えます）。Create route を選択します。

デバイスを Cloudflare に接続するには:

1. デバイスに Cloudflare One Client をデプロイ し、Traffic and DNS モードにします。
2. Gateway プロキシを TCP 向けに有効にします。
3. デバイス登録ルールを作成 し、Zero Trust 組織に登録できるデバイスを決めます。

デフォルトでは、WARP は RFC 1918 空間 ↗ 向けのトラフィックを除外します。これはプライベートネットワークでよく使われ、インターネットから到達できない IP アドレスです。Cloudflare One Client が SSH server へトラフィックを送るには、Split Tunnels を設定し、SSH server の IP/CIDR が Cloudflare One Client 経由でルーティングされるようにします。

1. まず、Split Tunnels のモード が Exclude と Include のどちらになっているかを確認します。

2. モードに応じて Split Tunnel のルートを編集します。

   Exclude モードを使っている場合:

   a. SSH server の IP/CIDR 範囲を含む ルートを削除 します。たとえば、ネットワークが AWS のデフォルト範囲 172.31.0.0/16 を使っている場合は、172.16.0.0/12 を削除します。

   b. SSH server が明示的に使っていない IP/CIDR 範囲を再追加 します。上記の AWS の例では、172.16.0.0/13、172.24.0.0/14、172.28.0.0/15、172.30.0.0/16 を新たに追加します。こうすると、172.31.0.0/16 向けのトラフィックだけが Cloudflare One Client 経由になります。

   再追加する IP アドレスは、次の計算機で求められます。

   Base CIDRSubtracted CIDRs

   Calculate

   計算機の使い方

   1. Base CIDR に、Split Tunnels から削除した RFC 1918 範囲を入力します。
   2. Subtracted CIDRs に、SSH server が使う IP/CIDR 範囲を入力します。
   3. 計算機の結果を Split Tunnel の Exclude モードのリストに戻します。

   Cloudflare One Client に含めるプライベート IP 範囲を狭めると、ユーザーの ローカルリソースへのアクセス を壊すリスクを下げられます。

   Include モードを使っている場合:

   1. 必要な Zero Trust ドメイン または IP アドレス を Split Tunnel の include リストに追加します。
   2. SSH server の IP/CIDR 範囲を含める ルートを追加 します。

ターゲットは、ユーザーが Cloudflare 経由で接続するインフラ上の 1 つのリソースです（サーバー、Kubernetes クラスター、データベース、コンテナなど）。

ターゲットはプロトコル非依存です。サーバー上で動くプロトコルごとに新しいターゲットを定義する必要はありません。新しいターゲットを作成する手順は次のとおりです。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/infrastructure/targets" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "infra-access-target",
		"ip": {
				"ipv4": {
						"ip_addr": "187.26.29.249",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				},
				"ipv6": {
						"ip_addr": "64c0:64e8:f0b4:8dbf:7104:72b0:ec8f:f5e0",
						"virtual_network_id": "c77b744e-acc8-428f-9257-6878c046ed55"
				}
		},
		"tags": {
				"environment": "production",
				"team": "platform"
		}
	}'

次に、ターゲットを保護する Access アプリケーションを作成します。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Example infrastructure app",
		"type": "infrastructure",
		"target_criteria": [
				{
						"port": 22,
						"protocol": "SSH",
						"include": {
								"target_attributes": {
										"hostname": [
												"infra-access-target"
										]
								},
								"tags": {
										"environment": [
												"production",
												"staging"
										]
								}
						},
						"require": {
								"tags": {
										"team": [
												"platform"
										]
								}
						},
						"exclude": {
								"tags": {
										"lifecycle": [
												"decommissioned"
										]
								}
						}
				}
		],
		"policies": [
				{
						"name": "Allow a specific email",
						"decision": "allow",
						"include": [
								{
										"email": {
												"email": "[email protected]"
										}
								}
						],
						"connection_rules": {
								"ssh": {
										"usernames": [
												"root",
												"ec2-user"
										]
								}
						}
				}
		]
	}'

このアプリケーション内のターゲットは、インフラストラクチャポリシーで保護されます。

Cloudflare One Client からインフラストラクチャターゲットへのトラフィックは、Gateway ネットワークポリシー と、アプリケーション固有の Access ポリシーの両方でフィルタリングされます。

Cloudflare One Client のユーザーがプライベートネットワーク全体にアクセスできないようにするには、プライベート IP 空間向けの キャッチオール Gateway Block ポリシー を作成することを推奨します。そのうえで、特定のアプリケーションや IP へのアクセスを許可する、優先度の高い Allow ポリシー（Access または Gateway）を重ねます。

デフォルトでは、Cloudflare はすべての Gateway のネットワークポリシー を評価したあとで、Access アプリケーションポリシーを評価します。特定の Gateway ポリシーの前または後に Access アプリケーションを評価するには:

1. Cloudflare ダッシュボード ↗ で、Zero Trust > Traffic policies > Firewall policies を開きます。Network で、次の構成の ネットワークポリシーを作成 します。

   セレクター	演算子	値	アクション
   Access Infrastructure Target	is	Present	Allow

2. ダッシュボードまたは API を使い、ポリシーの 優先順位 を更新します。

この Gateway ポリシーは、RDP と SSH を含む、すべての Access for Infrastructure ターゲットに適用されます。

次に、SSH サーバーが Cloudflare SSH CA を信頼するよう設定します。従来の SSH キーではなく、短期間有効な証明書で Access が認証できるようになります。

Cloudflare SSH CA を生成し、公開鍵を取得するには:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/gateway_ca" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

1. 次のコマンドで、リモートの対象マシン上の SSH 設定ディレクトリに移動します。

   cd /etc/ssh

2. 移動したら、次のコマンドでファイルを生成し、テキストエディターで公開鍵を入力または貼り付けます。

   vim ca.pub

3. ca.pub ファイルに、公開鍵を変更せずに貼り付けます。

   ecdsa-sha2-nistp256 <redacted> [email protected]

   ca.pub ファイルには複数の鍵を、1 行に 1 つずつ記入できます。空行と、# で始まるコメントも使えます。

4. ca.pub ファイルを保存します。一部のシステムでは、権限によっては次のコマンドで強制的に保存する必要があります。

   :w !sudo tee %
   :q!

リモートの対象マシンで sshd_config ファイルを更新し、SSH サーバーが Cloudflare SSH CA を信頼するように設定します。

1. リモートマシンの /etc/ssh ディレクトリで、sshd_config ファイルを開きます。

    sudo vim /etc/ssh/sshd_config

2. i を押して挿入モードに入り、ファイルの先頭（ほかのディレクティブより上）に次の行を追加します。

   PubkeyAuthentication yes
   TrustedUserCAKeys /etc/ssh/ca.pub

3. esc を押し、:x と入力して Enter を押し、保存して終了します。

sshd の設定を変更したら、変更を反映するためにリモートマシンで SSH サービスを再読み込みします。

sudo systemctl reload ssh

sudo systemctl reload sshd

SSH サーバーへ接続する前に、PIV キーまたは FIDO2 キーでの認証をユーザーに求められます。カスタム MFA を設定するときは、PIV key、FIDO2 key、またはその両方を選びます。

SSH 向けの独立 MFA を設定するには、インフラストラクチャアプリケーションに MFA を適用する を参照してください。

MFA を有効にした状態で接続するには、ユーザーがキーを登録し、SSH クライアントを設定する必要があります。

• PIV キーの場合は、キーを登録 し、SSH クライアントを設定 します。
• FIDO2 キーの場合は、キーを登録 し、SSH クライアントを設定 します。

ユーザーが ssh <username>@<target IP> を実行すると、SSH プロキシは一致するポリシーで MFA が必須かを確認します。必須なら、ユーザーはハードウェアキーで認証します。タッチ、PIN、またはその両方が求められるかは、設定した PIV キーポリシー、または FIDO2 キー自身の設定によります。その後、プロキシが接続を完了します。

ユーザーは、Cloudflare One Client にログインした状態であれば、任意の SSH クライアントを使えます。ターゲットが仮想ネットワークを使う場合は、先に その仮想ネットワークへ接続 します。

ssh <username>@<target IP>

Access for Infrastructure は scp、sftp、rsync コマンドにも対応します。未対応の SSH コマンドと機能は 既知の制限 を参照してください。

ユーザー接続の詳細は、Access for Infrastructure のドキュメント を参照してください。

SSH コマンドログには、ユーザーがターゲット上で実行した実際の SSH コマンドが含まれます。すべてのプランのお客様は、SSH ログを Cloudflare に保存し、ダッシュボードからダウンロードできます。ダウンロード可能なログ は、お客様が提供する公開鍵で暗号化され、Cloudflare からは見えません。ダウンロード可能な SSH ログの配信はベストエフォートです。確実な配信が必要な Enterprise のお客様は、Logpush ジョブを設定 して SSH ログを保存先へ送れます。Logpush のペイロードは、お客様提供の公開鍵では暗号化されません。

次の手順で、Zero Trust から SSH コマンドログを暗号化してダウンロードします。

SSH コマンドを記録するには、HPKE 鍵ペアを生成し、公開鍵を Cloudflare にアップロードします。

1. Cloudflare の ssh-log-cli ユーティリティを ダウンロード ↗ します。

2. ssh-log-cli ユーティリティで、公開鍵と秘密鍵のペアを生成します。

   ./ssh-log-cli generate-key-pair -o sshkey
   ls

   README.md    ssh-log-cli    sshkey    sshkey.pub

   このコマンドは、公開鍵 sshkey.pub と、対になる秘密鍵 sshkey の 2 つのファイルを出力します。

3. Cloudflare ダッシュボード ↗ で Zero Trust > Traffic policies > Traffic settings を開きます。

4. SSH log encryption public key に sshkey.pub の内容を貼り付け、Save を選びます。

プロキシされた SSH コマンドはすべて、この公開鍵ですぐに暗号化されます。ログを表示するには、対になる秘密鍵が必要です。

SSH コマンドログをオフにするには、アップロードした公開鍵を削除します。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/audit_ssh_settings" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"public_key": ""
	}'

SSH コマンドログはダッシュボード上では見えず、エクスポートして復号する必要があります。

ログを手動で取得するには:

1. Cloudflare ダッシュボード ↗ で Zero Trust > Insights > Logs を開きます。
2. SSH command logs を選択します。
3. SSH アプリケーション の名前でログを絞り込みます。
4. コマンドログをエクスポートする SSH セッションを選びます。
5. サイドパネルで SSH logs までスクロールし、Download を選択します。

6. ログを復号するには、SSH Logging CLI リポジトリ ↗ の手順に従います。次の例では、sshkey は Cloudflare にアップロードした公開鍵と対になる秘密鍵です。

   ./ssh-log-cli decrypt -i sshlog -k sshkey

   このコマンドは、復号済みログを含む sshlog-decrypted.zip ファイルを出力します。

Cloudflare では、Logpush に設定した保存先（サードパーティの保存先を含む）へ SSH コマンドログを送れます。利用できるデータフィールドは SSH logs データセット を参照してください。

Logpush ジョブの設定は Logpush 連携 を参照してください。

次の SSH 機能は未対応です。

• ローカルおよびリモートのポートフォワーディング
• ProxyJump
• SSH エージェントフォワーディング
• X11 フォワーディング

SSH セッションの想定最大時間は 10 時間です。詳細は Access のトラブルシューティング を参照してください。

SSH エンドポイントへの接続失敗は、複数の要因が原因になり得ます。次の手順で原因を調べ、解消します。

1. Access ポリシーを確認 し、ユーザーがターゲットへアクセスできることを確かめます。
2. ユーザーのデバイスプロファイルを確認 し、ターゲットが Cloudflare One Client 経由でルーティングされることを確かめます。
3. Cloudflare Tunnel の健全性を確認します。
4. サーバー上の ユーザーの存在を確認 します。
5. sshd_config ファイル の設定誤りを確認します。

明示的な許可 Access ポリシーがなく、Access がデフォルトでユーザーを拒否しているため、Access ポリシーでサーバー到達がブロックされることがあります。

エンドユーザーは warp-cli target list を実行し、ターゲットへのアクセスがあることを確認します。

warp-cli target list

╭──────────────────────────────────────┬──────────┬───────┬───────────────────────┬──────────────────────┬────────────╮
│ Target ID                            │ Protocol │ Port  │ Attributes            │ IP (Virtual Network) │ Usernames  │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 22    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ alice      │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 0193f22a-9df3-78e3-b5bb-7ab631903306 │ SSH      │ 23    │ hostname: do-target   │ 10.116.0.3 (a1net)   │ root       │
├──────────────────────────────────────┼──────────┼───────┼───────────────────────┼──────────────────────┼────────────┤
│ 01943cff-6130-7989-8bff-cbc02b59a2b1 │ SSH      │ 80    │ hostname: az-target   │ 172.16.0.0 (b1net)   │ alice, bob │
╰──────────────────────────────────────┴──────────┴───────┴───────────────────────┴──────────────────────┴────────────╯

• ターゲットが一覧に出る場合は、接続しようとしているユーザー名が出力に表示されることを確認します。ユーザー名が無い場合、管理者がターゲットに関連する Access ポリシーを見つけ、そのユーザー名を Access ポリシーに追加する必要があります。管理者は 手順 5 のサブステップ 9: インフラストラクチャアプリケーションを追加する で Access ポリシーを作成しているはずです。ユーザー名が表示されていれば、Access ポリシーはアクセスを許可しているはずです。クライアントルーティングを確認 に進みます。

• ターゲットが一覧に出ない場合、管理者が Cloudflare One でターゲットの Access ポリシーを監査し、接続をブロックしている設定誤りがないか確認する必要があります。

管理者は、エンドユーザーデバイスで warp-cli target list を実行する代わりに、Access ログで Access ポリシーが接続問題の原因かを確認できます。エンドユーザーに代わって接続問題を調べるときにログ確認が役立ちます。

1. Cloudflare ダッシュボード ↗ で Zero Trust > Insights > Logs を開きます。

2. Access authentication logs を選択します。

3. テスト中のアプリケーションを選ぶか、App Type として Infrastructure で絞り込みます。

4. Decision を確認します。Decision が Access denied の場合は、アプリケーションを選び、App の下の名前をコピーします。

   判定が Access granted の場合は、クライアントルーティングを確認 に進みます。

5. Access controls > Applications を開きます。

6. 検索バーにアプリ名を入力し、アプリケーションを選びます。

7. Configure を選択します。

8. Policies を開き、ユーザーをブロックしている条件を確認します。

ユーザーを許可する Access ポリシー を追加すると、接続問題は解消するはずです。ポリシーの変更を保存したあと、サーバーへの接続を試します。

Access ポリシーを確認しても接続できない場合は、次の手順でクライアントルーティング設定を確認します。

ターゲットの IP アドレスは Cloudflare One Client 経由でルーティングする必要があります。別のデバイスプロファイルに一致すると、デバイスが想定と異なる Split Tunnel 構成を受け取ることがあります。

有効なプロファイルとその Split Tunnel 構成を確認するには:

1. Cloudflare ダッシュボード ↗ で Zero Trust > Team & Resources > Devices を開きます。
2. ユーザーのデバイスを見つけ、Last active device profile を控えます。
3. Team & Resources > Devices > Device profiles > General profiles を開きます。
4. 有効なプロファイルを編集し、Split Tunnels を開きます。
5. ターゲットの IP アドレスまたは CIDR が Cloudflare One Client 経由でルーティングされることを確認します。設定手順は Split Tunnels を参照してください。
6. プロファイルが identity.email セレクターを使う場合、そのメールがインフラストラクチャアプリケーションポリシーで許可されている ID と一致することを確認します。

接続試行が Access authentication logs に出ない場合は、トンネルや SSH サーバーを確認する前に、クライアントルーティング設定を直してください。

エンドユーザーがターゲットに接続できない場合、手順 1: サーバーを Cloudflare に接続する でセットアップしたトンネルがダウンまたは非アクティブの可能性があります。

トンネルの状態を確認するには:

1. Cloudflare ダッシュボードで Networking > Routes を開きます。

   Routes を開く ↗

2. IP を検索し、ルートと関連するトンネルを見つけます。

   この IP は 前の手順 の warp-cli target list 出力に表示されます。管理者の場合は Networks > Targets を開き、Hostname の横の IP でも確認できます。

3. Connector 列のトンネル名を選び、トンネル詳細ページを開きます。

4. Tunnel status が Active で、Down、Degraded、Inactive ではないことを確認します。

詳しいトラブルシューティング手順は トンネルのトラブルシューティング を参照してください。ネットワークが cloudflared 接続を許可するよう正しく設定されているかは、ファイアウォール付きトンネル を確認してください。

トンネルの健全性に問題が無いことを確認したら、次の手順でサーバー上のユーザーの存在を確認します。

UNIX サーバー上のユーザーの存在を確認するには、サーバーで id <USERNAME> コマンドを実行し、ユーザー名があることを確かめます。ユーザー名が無い場合は、サーバーにユーザーを追加する必要があります。

ユーザーがサーバー上にいる場合は、次の手順で sshd_config ファイルをデバッグします。

SSH エンドポイントへの接続失敗の一因として、sshd_config の設定誤りがあります。次の手順で sshd_config を確認します。

sshd ログで、ユーザーがサーバーまで到達しているかを確認できます。ログの場所は sshd_config で定義されます。Ubuntu では journalctl -u ssh、Red Hat では tail /var/log/auth.log であることが多いです。

sshd ログで、SSH 接続試行がサーバーに届いていることを確認します。

sshd_config の問題を切り分けるには、既存の sshd_config を次の例と比べ、認証に影響するディレクティブが無いか確認します。次の例の sshd_config では認証が成功します。

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

PubkeyAuthentication yes
TrustedUserCAKeys /etc/ssh/ca.pub

Include /etc/ssh/sshd_config.d/*.conf

# When systemd socket activation is used (the default), the socket
# configuration must be re-generated after changing Port, AddressFamily, or
# ListenAddress.
#
# For changes to take effect, run:
#
#   systemctl daemon-reload
#   systemctl restart ssh.socket
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG3

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10



# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin yes
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem    sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

sshd ログで証明書が CA 署名として受け入れられているのに接続が失敗する場合、アカウントが証明書のプリンシパルを許可していないことがあります。sshd は次のように報告します。

Certificate invalid: name is not a listed principal

接続先アカウントの実効設定を確認します。これらのディレクティブは Match ブロック内で設定されていることが多いです。

sudo sshd -T -C user=<USERNAME> | grep -i principals

authorizedprincipalsfile または authorizedprincipalscommand が none 以外の値なら、そのファイルまたはコマンド出力に SSH ユーザー名があることを確認します。無い場合は追加し、sudo sshd -t で設定を検証してから、SSH サーバーを 再読み込み します。

次の手順は切り分け用です。既存の sshd_config を一時的に提供例へ置き換え、設定問題を除外します。進める前に、両方のファイルをよく見比べ、衝突するディレクティブを特定してください。

1. 既存の sshd_config ファイルをバックアップします。

   mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

2. 新しい sshd_config ファイルを作成します。

   vi /etc/ssh/sshd_config

3. キーボードの i キーを押し、挿入モードにします。

4. 例のファイル を貼り付けます。

5. Escape（esc）キーを押し、挿入モードを終了します。

6. :x を入力して保存して終了します。

7. SSH サーバーを 再読み込み します。

   sshd の設定を変更したら、変更を反映するためにリモートマシンで SSH サービスを再読み込みします。

   Debian/Ubuntu の場合:

   sudo systemctl reload ssh

   CentOS/RHEL 7 以降の場合:

   sudo systemctl reload sshd

これらのトラブルシューティング手順のあと、接続を再試行します。問題が続く場合は、sshd ログを再確認 します。上記の例の sshd_config はデバッグログを有効にしており、より具体的な問題が見えることがあります。

できるだけ早く切り分けるため、サポートチケットには十分な詳細を含めてください。状況が多いほど、問題の特定と解決が早くなります。

サポートへ連絡する ときは、チケットにできるだけ関連する詳細を含めてください。

• 状況: シナリオや用途を短く説明します（たとえば、ユーザーがどこにいて、何をしようとしていたか）。

• 再現手順: トラブルシューティング中に問題を再現した手順を説明します。

• タイムスタンプ: 問題が発生した正確な時刻とタイムゾーンを含めます。

• 試した対処: すでに試したトラブルシューティング手順や変更を示します。

• sshd デバッグレベルのログ: 手順 4: sshd_config の設定誤りをデバッグする で収集した sshd ログを添付します。

• sshd_config ファイル: サーバーの sshd_config のコピーを含め、設定誤りや衝突するディレクティブの特定に役立てます。

• クライアント側の SSH 出力: 失敗した SSH コマンドを詳細フラグ（-vvv）付きで実行し、クライアント側の接続と認証試行が分かるよう、ターミナル出力をすべて含めます。