1. TL;DR（結論）

Windows OpenSSH Serverにおいて、接続先ユーザーがAdministratorsグループに所属している場合、セキュリティ仕様によりユーザーフォルダ内の ~/.ssh/authorized_keys は無視されます。

以下の手順で解決できる可能性があります。

公開鍵を C:\ProgramData\ssh\administrators_authorized_keys に配置する。
icacls コマンドで、当該ファイルの権限を「SYSTEM」と「Administrators」のみに厳密に限定する。

2. 環境

Server OS: Windows 11 (24H2)
OpenSSH Server: OpenSSH_for_Win64 9.5p1 以降
Subsystem: WSL2 (Ubuntu 24.04)
Network: Tailscale (ポート開放不要のVPN)
Client: Android (Termius) / Windows PC

3. 直面したエラー

Android端末（Termius）からTailscaleのIPアドレス経由でWindows PCへSSH接続を試みた際、クライアント側で公開鍵を設定しているにもかかわらず、パスワード入力を求められる。

$ ssh -v user@100.x.y.z
...
debug1: Next authentication method: publickey
debug1: Offering public key: /data/.../id_ed25519 ED25519 ...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Next authentication method: password
user@100.x.y.z's password:

MicrosoftアカウントでWindowsにログインしている場合、SSH用のパスワード（旧来のローカルアカウントパスワード）が存在しない、または無効化されていることが多く、ログイン不能となる。

4. 解決手順

WindowsのPowerShell（管理者権限）を使用して設定を行います。

4.1 sshd_config の確認

まず、設定ファイル C:\ProgramData\ssh\sshd_config を確認します。
デフォルトでは、管理者ユーザーは administrators_authorized_keys を参照するように設定されています。以下の設定が有効になっているか確認します。

# sshd_config (抜粋)
PubkeyAuthentication yes

# 管理者グループ用の設定（ファイル末尾付近）
Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

ポイント：

PubkeyAuthentication yes が有効であること。
Match Group administrators ブロックが存在し、AuthorizedKeysFile が __PROGRAMDATA__/ssh/administrators_authorized_keys を指していること。

4.2 administrators_authorized_keys の作成

管理者権限のメモ帳、またはPowerShellでファイルを作成し、クライアント（Android等）で生成した公開鍵（ssh-rsa ... や ssh-ed25519 ...）を貼り付けます。

# フォルダがない場合は作成
New-Item -ItemType Directory -Force -Path "C:\ProgramData\ssh"

# ファイルの作成（メモ帳で開く）
notepad C:\ProgramData\ssh\administrators_authorized_keys

注意点：

公開鍵は改行を含まない1行で記述すること。
文字コードはUTF-8（BOMなし推奨）で保存すること。
複数の公開鍵を登録する場合は、1行ずつ改行で区切る。

4.3 【重要】icacls による権限設定

単にファイルを置いただけでは、権限が緩すぎるためOpenSSH Serverがセキュリティ上の理由で読み込みを拒否します（これがパスワード認証にフォールバックする原因です）。

4.3.1 権限設定前の確認（任意）

現在の権限を確認したい場合は、以下のコマンドを実行します。

Get-Acl "C:\ProgramData\ssh\administrators_authorized_keys" | Format-List

4.3.2 権限の厳格化

以下のコマンドをPowerShell（管理者）で実行し、権限を「Administrators」と「SYSTEM」のみに絞ります。

# 対象ファイルのパスを変数にセット
$path = "C:\ProgramData\ssh\administrators_authorized_keys"

# 1. 権限の継承を無効化(/inheritance:r)
# 2. 管理者グループにフルコントロールを付与(/grant "Administrators:F")
# 3. SYSTEMにフルコントロールを付与(/grant "SYSTEM:F")
icacls $path /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

実行後、正常に処理されました と表示されれば完了です。

4.3.3 権限設定後の確認（推奨）

再度権限を確認し、Administrators と SYSTEM のみがアクセス権を持っていることを確認します。

Get-Acl "C:\ProgramData\ssh\administrators_authorized_keys" | Format-List

4.4 サービスの再起動

設定を反映させるため、SSHサーバーサービスを再起動します。

Restart-Service sshd

4.5 接続テスト

クライアント側から再度SSH接続を試みます。

ssh user@100.x.y.z

パスワードを求められることなく、Windowsのプロンプトが表示されれば成功です。

注意: 環境によっては追加の設定が必要になる場合があります。詳細はトラブルシューティング（6章）を参照してください。

5. 補足：WSL2開発環境の快適化

SSH接続後、WindowsのコマンドプロンプトからWSL2（Ubuntu）内の開発ツール（Claude Code等）を快適に扱うためのTipsです。

5.1 Tailscaleによるネットワーク構築

ポート開放（ルーター設定）を行わず、安全に外部から接続するためにTailscaleを利用しました。

Windows側: Tailscaleアプリをインストールしログイン。
Android側: Tailscaleアプリをインストールし、同じアカウントでログイン。
接続: Tailscaleが割り当てたIP（例: 100.x.y.z）またはMagicDNS名（例: windows-pc）をホスト名としてSSH接続する。

5.2 WSL2への自動接続とtmuxの活用

SSH接続後、毎回 wsl コマンドを打つ手間を省き、かつ回線切断時もセッションを維持するために、WSL2側の .bashrc に以下のエイリアスを設定しました。

# ~/.bashrc に追記
alias c='tmux attach -t claude-session || tmux new -s claude-session claude'

運用の流れ：

Termius等のSSHクライアントでWindowsに接続。
wsl と入力してUbuntuに入る。
c と入力してEnter。
- 既存セッションがあれば復帰（アタッチ）。
- なければ新規に claude を起動。

これにより、モバイル回線が不安定な環境でも、再接続後に即座に作業を再開できる環境が整います。

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

6.1 それでも接続できない場合

以下を確認してください。

ファイアウォール設定: Windows Defenderファイアウォールでポート22（SSH）が許可されているか確認。
公開鍵の形式: ssh-ed25519 または ssh-rsa で始まる1行の文字列になっているか確認。
sshdサービスの状態: Get-Service sshd で "Running" になっているか確認。

6.2 ログの確認方法

詳細なデバッグには、sshd側のログが有効です。

# PowerShellでイベントログを確認
Get-WinEvent -LogName "OpenSSH/Operational" -MaxEvents 20 | Format-Table -Wrap

まとめ

Windows OpenSSH Serverでの公開鍵認証トラブルは、管理者グループ特有の administrators_authorized_keys 仕様と、厳格な権限要件が原因であることが多いようです。

ポイント：

管理者ユーザーは ~/.ssh/authorized_keys が無視される。
C:\ProgramData\ssh\administrators_authorized_keys に公開鍵を配置。
icacls で権限を Administrators と SYSTEM のみに制限。

この設定で、多くの環境において外出先からでも自宅Windows PCへアクセスできるようになります。ただし、環境差異により追加の設定が必要になる場合もあるため、うまくいかない場合は公式ドキュメントやコミュニティの情報も参照してください。

追記（2026年1月）

本記事のコメントで「mirrored mode を使えばWSL2に直接SSH接続できる」とアドバイスをいただき、実際に試してみました。

WSL2への直接接続を実現できましたが、mirrored mode環境ではポート空間がWindowsと共有されるため、ポート競合という新たな問題に遭遇しました。

解決過程を以下の記事にまとめています：

WSL2 + Tailscaleでポート競合を解決してSSH直接接続

Windows経由せずWSL2に直接接続したい方は、ぜひご覧ください。