WindowsのOpenSSHで鍵認証ログインを安定させる近道は、authorized_keys の置き場所をユーザー種別で正しく分け、NTFSのACLを最初に整え、Linux向けの設定例をそのまま流用しないことです。特に管理者ユーザーは通常ユーザーと鍵ファイルの場所が違うため、そこを外すだけで Permission denied (publickey) になりやすくなります。さらに、Windows標準搭載版には使えないディレクティブがあり、バージョン差やPATH競合まで含めて見ないと「設定は合っているのに不安定」という状態になりがちです。 (Microsoft Learn)
この記事では、WindowsのOpenSSHで鍵認証を安定させるための設定順序、詰まりやすいポイント、切り分け手順、代替策までを実務目線で整理します。ローカルアカウントとActive Directoryアカウントの違い、管理者ユーザーの注意点、古いクライアントとの互換問題もまとめて把握できます。 (Microsoft Learn)
まず押さえるべき3つの結論
- 標準ユーザーなら公開鍵は
C:\Users\<ユーザー名>\.ssh\authorized_keys、管理者グループ所属ユーザーなら%ProgramData%\ssh\administrators_authorized_keysが既定です。ここを取り違えると、他が正しくても鍵認証は通りません。 (Microsoft Learn) - WindowsではLinuxの
chmod/chownよりもACLが重要です。特にadministrators_authorized_keysはSYSTEMとAdministratorsだけが扱える状態に整える必要があります。 (Microsoft Learn) - Windows標準搭載版のOpenSSHでは、
StrictModesやAuthorizedKeysCommandなど、Linux解説でよく出てくる設定が使えないものがあります。Linux記事をそのまま写すより、Windowsの仕様差を前提にした方が安定します。 (Microsoft Learn)
WindowsのOpenSSHで鍵認証が不安定になりやすい理由
管理者ユーザーだけ鍵の置き場所が変わる
Windows版OpenSSHの大きな落とし穴は、管理者グループ所属ユーザーだけ公開鍵の置き場所が変わることです。通常ユーザーはホーム配下の .ssh\authorized_keys を使いますが、管理者は %ProgramData%\ssh\administrators_authorized_keys を使います。Linuxの感覚で全員 C:\Users\<user>\.ssh\authorized_keys にそろえると、管理者ユーザーだけ失敗します。 (Microsoft Learn)
不安定に見える原因の多くはACL
Windowsでは、鍵認証の失敗が「鍵が違う」よりも「ファイルの権限が広すぎる・違う場所にある」で起きやすいです。Microsoft Learn でも、管理者用の administrators_authorized_keys は NT Authority\SYSTEM と BUILTIN\Administrators だけの権限構成にするよう案内しています。まずACLを直す、という順番にするだけで切り分けがかなり楽になります。 (Microsoft Learn)
標準搭載版と最新GitHub版で前提がズレる
Windows標準搭載版のOpenSSHはMicrosoftサポートの対象で安定しやすい一方、更新はWindows Updateのタイミングに寄るため、GitHub版のWin32-OpenSSHより機能や修正が遅れやすい傾向があります。記事や検証メモによって前提バージョンが違うと、同じ設定でも再現性がずれます。 (Microsoft Learn)
失敗しにくい構築手順
日常運用は、できるだけ標準ユーザーから始める
鍵認証を安定させたいだけなら、最初の構築対象は標準ユーザーの方がシンプルです。公開鍵の保存先がユーザーごとに閉じるため、管理者共通ファイルのACLや鍵の棚卸しで悩みにくくなります。WindowsのOpenSSHの鍵認証は、ローカルWindowsアカウントとActive Directoryアカウントで使えますが、Microsoft Entra ID アカウントは対象外です。 (Microsoft Learn)
管理者ユーザーで直接入る構成は、緊急保守や初期構築では便利です。ただし、運用が長くなるほど「誰の鍵が入っているか」「不要な鍵が残っていないか」を追いにくくなります。日常作業や自動化は標準ユーザー、必要時だけ昇格、という分け方の方が安定しやすいです。
公開鍵は .pub の1行をそのまま登録する
authorized_keys は1行に1本の公開鍵を置く形式です。コメント欄は識別用に使えますが、認証の本体ではありません。貼り付けるのは秘密鍵ではなく、あくまで .pub 側です。標準ユーザーなら C:\Users\<ユーザー名>\.ssh\authorized_keys、管理者なら C:\ProgramData\ssh\administrators_authorized_keys に登録します。 (OpenBSD Manual Pages)
クライアント側の鍵生成では、ssh-keygen でアルゴリズム指定を省略すると Ed25519 が使われます。新しめのOpenSSH同士であれば、まずはこの既定値で始めるのが無難です。パスフレーズを付けたうえで ssh-agent と ssh-add を併用すると、毎回の入力負荷を抑えつつ安全性も落としにくくなります。 (Microsoft Learn)
管理者用ファイルのACLは最初に固定する
管理者ユーザーで鍵認証するなら、公開鍵の登録よりACLの固定を先にやった方が安定します。最低限、次の形を基準にしてください。
icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"Microsoft Learn でも、administrators_authorized_keys には SYSTEM と Administrators 以外の権限を残さない構成が案内されています。日本語OSなどでグループ名の表記差分に引っかかる場合は、Administrators の代わりに SID 形式 *S-1-5-32-544 を使う方法も案内されています。 (Microsoft Learn)
sshd_config は最小限から始める
Windowsで安定させたいときほど、sshd_config は最小限にした方が成功しやすいです。ファイルは %ProgramData%\ssh\sshd_config にあり、変更はサービス再起動まで反映されません。 (Microsoft Learn)
最初は次のような構成で十分です。
# C:\ProgramData\ssh\sshd_config
PubkeyAuthentication yes
PasswordAuthentication yes
# トラブル調査時だけ一時的に使う
# SyslogFacility LOCAL0
# LogLevel VERBOSE
# 接続対象を絞る例
# AllowGroups sshusersここで大事なのは、最初から AuthorizedKeysFile をいじらないことです。Windowsは既定で、通常ユーザーと管理者ユーザーで鍵ファイルの扱いを分けています。グローバルに AuthorizedKeysFile を上書きすると、そのWindows固有の既定動作を自分で壊しやすくなります。 (Microsoft Learn)
また、AllowUsers や AllowGroups を使うなら、アカウント名・グループ名は小文字で書く前提です。WindowsのドメインユーザーやグループにはWindows固有の表記ルールがあるため、まずはローカルグループで通ることを確認し、その後にAD連携へ広げる方が失敗しにくいです。 (Microsoft Learn)
変更後は必ず構文確認してから再起動する
設定変更後にいきなり再接続するのではなく、まずサーバー側で構文確認を入れます。
sshd -t
Restart-Service sshdクライアント側は、少なくとも最初の検証では詳細表示つきで接続します。
ssh -v user@serversshd -t はMicrosoft LearnでもWindowsでの確認手順として案内されています。ログを増やしたいときは LogLevel VERBOSE から始め、必要に応じてファイル出力へ切り替えるのが現実的です。OpenSSHのマニュアルでも、DEBUG系は出力が過剰でプライバシー上の注意が必要とされています。 (Microsoft Learn)
実務で多い失敗パターンと直し方
Permission denied (publickey) が出る
このエラーが出たら、確認順はほぼ決まっています。
- 対象ユーザーは管理者グループ所属ではないか。所属しているなら、鍵は
%ProgramData%\ssh\administrators_authorized_keys側に置く必要があります。 (Microsoft Learn) administrators_authorized_keysのACLが崩れていないか。余計な継承や権限が残っていないかを見ます。 (Microsoft Learn)AllowUsers/AllowGroups/DenyUsers/DenyGroupsで弾いていないか。Windowsではこれらの評価順が決まっており、名前は小文字で書く前提です。 (Microsoft Learn)- そもそも
sshd_configの変更が再起動前で止まっていないか。Windows版はサービス起動時に設定を読み込みます。 (Microsoft Learn)
パスワード認証は通るのに、鍵認証だけ失敗する
この症状はネットワークではなく、鍵ファイルの場所・内容・ACLの問題であることが多いです。公開鍵は .pub の1行をそのまま入れ、通常ユーザーと管理者ユーザーの保存先を混同しないことが最優先です。Microsoftのトラブルシュートでも、authorized_keys 不在や権限不備は典型原因として挙げられています。 (OpenBSD Manual Pages)
Connection refused やポート未到達になる
これは鍵認証以前の問題です。Get-Service sshd、netstat -an | findstr :22、ファイアウォールの OpenSSH-Server-In-TCP、Event Viewer の Applications and Services Logs > OpenSSH を確認してください。ここが通っていない状態で鍵だけ見直しても前に進みません。 (Microsoft Learn)
古いクライアントだけ接続できない
OpenSSH 8.8 以降では、セキュリティ上の理由で ssh-rsa が既定で無効になっており、レガシー環境だけ失敗することがあります。どうしても暫定対応が必要なら、次の追加で回避できるケースがあります。
PubkeyAcceptedAlgorithms +ssh-rsa
HostKeyAlgorithms +ssh-rsaただし、これは恒久策ではありません。実務では、まず古いクライアントやサーバーの更新余地を確認し、やむを得ない場合だけ一時的に有効化する方が安全です。 (Microsoft Learn)
鍵認証では入れるのに、共有フォルダや別サーバーの統合認証が使えない
これは「鍵認証が不安定」ではなく、Windows版OpenSSHの仕様です。鍵ベースで開いたリモートセッションには、そのユーザーの資格情報が関連付かないため、ログイン後のセッションはそのままユーザーとしてのアウトバウンド認証ができません。共有フォルダや別サーバーへの統合認証まで必要な運用では、認証設計そのものを見直した方が早いです。 (Microsoft Learn)
認証後すぐ切れる
認証そのものが成功しているなら、鍵よりも既定シェルを疑う場面があります。Windowsでは、OpenSSHの既定シェルを HKLM\SOFTWARE\OpenSSH の DefaultShell で設定できます。PowerShellを既定シェルにしたい場合も、Microsoft Learn に設定例があります。 (Microsoft Learn)
再起動後だけ入れなくなる
初回の検証中は入れていたのに、再起動後に急に接続できなくなるなら、sshd サービスの起動種類を確認してください。Microsoft Learnでは Start-Service sshd に加え、Set-Service -Name sshd -StartupType Automatic が推奨されています。 (Microsoft Learn)
Linux向けの記事をそのまま適用しない
Windows標準搭載版のOpenSSHでは、Linuxの記事でよく見かける設定の一部がそのまま使えません。ここを知らないまま調整すると、設定を増やすほど不安定になります。 (Microsoft Learn)
StrictModesは、Windowsに標準搭載されるOpenSSHでは未対応です。ACLの問題をStrictModes yes/noで解決しようとしない方が安全です。 (Microsoft Learn)AuthorizedKeysCommandとAuthorizedKeysCommandUserも、標準搭載版では使えません。Linuxのように外部コマンドで動的に鍵を引く前提は、そのままでは乗りません。 (Microsoft Learn)PermitRootLoginはWindowsでは意味が違います。管理者のログイン制御はDenyGroups Administratorsの考え方で設計します。 (Microsoft Learn)
ここでのコツは、Windows固有の既定動作を崩さないことです。問題が出たときほど設定を増やしたくなりますが、まずは既定の保存先・既定の動作・正しいACLで通る状態を作る方が近道です。
使い回し鍵ではなく、用途別に絞ると事故が減る
鍵認証が安定してきたら、次は「通ればいい」から一歩進めて、鍵の用途を絞ると運用事故が減ります。OpenSSHの authorized_keys では、from= で接続元IPを制限し、command= で実行コマンドを固定し、restrict でポート転送やPTYをまとめて抑制できます。バックアップ専用鍵や自動化鍵では、ここまでやっておくと後から効きます。 (OpenBSD Manual Pages)
Windowsでも、この考え方は有効です。たとえば「社内CIサーバーからの配布だけ」「指定コマンドだけ許可」「対話シェル不要」といった自動化アカウントは、鍵認証の成功率だけでなく、失敗時の影響範囲まで小さくできます。
標準搭載版とGitHub版、どちらを使うべきか
結論からいうと、まずは標準搭載版で素直に動く構成を作るのがおすすめです。Microsoftサポートの範囲で動かせて、Windows Updateで維持しやすいからです。一方で、より新しい暗号方式や修正、新機能が必要なら、GitHub版のWin32-OpenSSHを検討する価値があります。Microsoft Learnでも、GitHub版は最新機能と修正を持つ一方で、手動更新が必要と説明されています。 (Microsoft Learn)
ただし、アップグレードは本番でいきなりやらない方が安全です。Microsoft Learn でも、アップグレード時は sshd が一時停止し、アクティブなSSHセッションが切断されるため、RDPやコンソールなど代替アクセス手段を確保し、まずステージング環境で検証するよう案内しています。 (Microsoft Learn)
アップグレード後や混在環境では、どの ssh.exe / sshd.exe を使っているかまで確認してください。Microsoft Learn でも、ssh -V と Get-Command ssh.exe | Select-Object Source で実体を確認し、古いフォルダがPATHの先頭に残っていないかを見るよう案内しています。PATH競合は、設定が正しいのに挙動だけおかしいときの見落としポイントです。 (Microsoft Learn)
迷ったときの判断基準
- 日常の運用や自動化なら、まずは標準ユーザー + ユーザープロファイル配下の
authorized_keysから始める。これが一番切り分けしやすいです。 (Microsoft Learn) - 管理者で直接入る必要があるなら、
administrators_authorized_keysとACL整備をセットで考える。片方だけだと安定しません。 (Microsoft Learn) - Active Directoryでアクセス制御をかけるなら、
AllowUsers/AllowGroupsの小文字ルールとWindows固有の表記を意識する。鍵より先にここで落ちることがあります。 (Microsoft Learn) - ログイン後に別サーバーや共有フォルダへ統合認証したいなら、鍵認証セッション単体では要件を満たしにくいと考える。設計段階で別の認証経路を検討した方が早いです。 (Microsoft Learn)
- 動的な鍵配布や最新機能が必要なら、標準搭載版の制約を認めたうえで、構成管理による配布やGitHub版の評価に進む。 (Microsoft Learn)
最後にやること
最初の一歩は、難しい設定を足すことではありません。対象ユーザーが管理者かどうかを確認し、正しい鍵ファイルの場所に公開鍵を置き、ACLを整えたうえで sshd -t と Restart-Service sshd を回す。これだけで、WindowsのOpenSSHの鍵認証はかなり安定します。 (Microsoft Learn)
そのうえで、ssh -v、Event Viewer の OpenSSH > Operational、必要なら %ProgramData%\ssh\logs を使って事実ベースで切り分けてください。まだ不安定なら、アルゴリズム互換、PATH競合、既定シェル、標準搭載版の制約の順に見ると、遠回りしにくくなります。 (Microsoft Learn)
コメント