Windows ServerでOpenSSHの鍵認証を使う場合、2026年4月の更新で注目すべき点は「認証方式そのものが大きく変わった」ことではなく、公開鍵を配置するPowerShell例と接続文字列が、実務で誤解しにくい形に整理されたことです。
特に管理者アカウントで鍵認証を設定する場合は、通常ユーザーとは公開鍵の配置先が異なります。標準ユーザーは C:\Users\username\.ssh\authorized_keys、管理者ユーザーは C:\ProgramData\ssh\administrators_authorized_keys を使う点を間違えると、パスワード認証は通るのに公開鍵認証だけ失敗します。
この記事では、Microsoft Learnの「Key-Based Authentication in OpenSSH for Windows」の2026年4月更新をもとに、Windows Server管理者が確認すべき変更点、設定手順、つまずきやすいポイントを実務向けに整理します。対象はWindows Server 2025、Windows Server 2022、Windows Server 2019でOpenSSH Serverを運用するIT管理者、Power User、技術選定担当者です。(GitHub)
Windows ServerのOpenSSH鍵認証で2026年4月に確認すべき更新ポイント
Microsoft Learnの該当ドキュメントは、Windows環境でOpenSSHの公開鍵認証を使うための基本手順を説明しています。2026年4月のGitHub履歴では、主に次の2点が更新されています。(GitHub)
| 更新日 | 更新内容 | 実務への影響 |
|---|---|---|
| 2026年4月21日 | 公開鍵をサーバーへ展開する例の接続文字列が ssh username@domain@hostname $remotePowershell に整理 | username、domain、hostname のどれを置き換えるべきか分かりやすくなった |
| 2026年4月16日 | 管理者向け公開鍵配置のPowerShell例で、引用符の扱いが修正 | administrators_authorized_keys へ公開鍵を書き込むスクリプトをコピーした際の失敗を減らせる |
| 継続して重要 | Microsoft Entra IDアカウントではOpenSSH for Windowsの鍵認証はサポートされない | クラウドIDだけで運用している環境では、認証設計を事前に見直す必要がある |
今回の更新は、新しい暗号方式の追加やOpenSSH Serverの仕様変更ではありません。むしろ、現場でよく起きる「サンプルコマンドをそのまま貼り付けたが動かない」「管理者なのに authorized_keys に置いてしまった」といった設定ミスを減らすためのドキュメント改善と見るべきです。
Key-Based Authentication in OpenSSH for Windowsとは
Key-Based Authentication in OpenSSH for Windowsは、ユーザー名とパスワードではなく、公開鍵と秘密鍵のペアでSSHログインする認証方式です。
Windows Serverでは、従来はドメイン参加した端末同士でユーザー名・パスワード認証を使う場面が多くありました。しかし、オンプレミスとクラウド、別ドメイン、踏み台サーバー、SFTP連携などをまたぐ環境では、パスワード認証だけに頼るとブルートフォース攻撃や資格情報の使い回しが問題になりやすくなります。
公開鍵認証では、クライアント側に秘密鍵、サーバー側に公開鍵を置きます。ログイン時に秘密鍵と公開鍵の対応関係が確認され、正しい秘密鍵を持つクライアントだけが認証されます。公開鍵はサーバーに置いてもよい情報ですが、秘密鍵はパスワードと同等、またはそれ以上に慎重に管理すべき情報です。
Windows版OpenSSHでは、主に次のツールを使います。(Microsoft Learn)
| ツール | 役割 |
|---|---|
ssh-keygen | 公開鍵・秘密鍵のペアを生成する |
ssh-agent | 秘密鍵をWindowsアカウントのセキュリティコンテキスト内で保持する |
ssh-add | 生成した秘密鍵を ssh-agent に登録する |
scp / sftp | 初回設定時の公開鍵転送やファイル転送に使う |
今回の更新で特に見直したい接続文字列の考え方
2026年4月21日の更新では、公開鍵をリモートサーバーへ展開するサンプルの接続先表記が、より一般化された形に変更されています。以前の例では具体的なドメイン風の文字列が使われており、ユーザー名、ドメイン名、ホスト名のどこを置き換えるのか分かりにくいケースがありました。(GitHub)
更新後の例では、次のように示されています。
ssh username@domain@hostname $remotePowershellこれは、UPN形式のユーザー名を使う場合に @ が2つ見える形になるため、初見では少し分かりにくいかもしれません。読み解くポイントは、最後の @hostname がSSH接続先のホストで、その前がログインユーザーを表す部分だという点です。
たとえば、環境によっては次のような使い分けになります。
| アカウント種別 | 接続例 | 補足 |
|---|---|---|
| ローカルユーザー | ssh localuser@server01 | 最も単純な形式 |
| ドメインユーザー | ssh domain\user@server01 | Windowsのドメインユーザー表記に近い |
| UPN形式のユーザー | ssh [email protected]@server01 | ユーザー名部分に @ が含まれる |
実務では、公開鍵を配置する前に、まずパスワード認証で対象ユーザーのSSHログイン表記が正しいか確認してください。ログイン名の表記が間違っていると、公開鍵の配置やACLが正しくても「鍵認証が失敗した」と誤解しやすくなります。
管理者アカウントと標準ユーザーで公開鍵の配置先が違う
Windows ServerのOpenSSH鍵認証で最も失敗しやすいのが、公開鍵ファイルの配置先です。
Linuxでは多くの場合、ユーザーごとのホームディレクトリにある ~/.ssh/authorized_keys を見れば済みます。しかしWindows版OpenSSHでは、対象ユーザーがローカルAdministratorsグループに属しているかどうかで参照されるファイルが変わります。
| 対象ユーザー | 公開鍵の配置先 | 注意点 |
|---|---|---|
| 標準ユーザー | C:\Users\username\.ssh\authorized_keys | ユーザープロファイル配下に配置 |
| 管理者ユーザー | C:\ProgramData\ssh\administrators_authorized_keys | ユーザー別の authorized_keys ではなく、管理者用ファイルを使う |
| Microsoft Entra IDアカウント | 非対応 | ローカルWindowsアカウントまたはActive Directoryアカウントで設計する |
管理者アカウントでログインするのに C:\Users\username\.ssh\authorized_keys へ公開鍵を置いても、期待どおりに認証されない場合があります。管理者ユーザーでは C:\ProgramData\ssh\administrators_authorized_keys を使う、という切り分けを最初に確認してください。
標準ユーザーで公開鍵認証を設定する手順
標準ユーザーであれば、公開鍵はユーザープロファイル配下の .ssh\authorized_keys に配置します。
まず、クライアント側で鍵ペアを生成します。Microsoft Learnの例ではECDSAを使っています。社内ポリシーで指定がない場合は、環境の標準に合わせてEd25519やECDSAを選びます。なお、アルゴリズムを指定しない場合、現在のドキュメントではEd25519が使われると説明されています。(Microsoft Learn)
ssh-keygen -t ecdsa生成後、秘密鍵と公開鍵は通常、次のように保存されます。
C:\Users\username\.ssh\id_ecdsa
C:\Users\username\.ssh\id_ecdsa.pub拡張子のない id_ecdsa が秘密鍵、.pub が付いた id_ecdsa.pub が公開鍵です。サーバーへ置くのは公開鍵だけです。秘密鍵をサーバーへコピーしてはいけません。
標準ユーザーの公開鍵配置例は次の流れです。
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ecdsa.pub
$remotePowershell = "powershell New-Item -Force -ItemType Directory -Path $env:USERPROFILE\.ssh; Add-Content -Force -Path $env:USERPROFILE\.ssh\authorized_keys -Value '$authorizedKey'"
ssh username@domain@hostname $remotePowershell実行時は、username@domain@hostname を自分の環境に合わせて置き換えます。ローカルユーザーであれば username@hostname のように簡略化できる場合があります。
管理者ユーザーで公開鍵認証を設定する手順
管理者ユーザーの場合、公開鍵は C:\ProgramData\ssh\administrators_authorized_keys に配置します。このファイルは管理者アカウント用であり、ユーザープロファイル配下の authorized_keys の代わりに使われます。(Microsoft Learn)
2026年4月16日の更新では、この管理者向けPowerShell例の引用符の扱いが修正されています。コピーして使う場合は、古い記事や社内手順書に残っている三重引用符の例をそのまま流用しないよう注意してください。(GitHub)
管理者ユーザー向けの基本例は次のとおりです。
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ecdsa.pub
$remotePowershell = "powershell Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value '$authorizedKey';icacls.exe ""$env:ProgramData\ssh\administrators_authorized_keys"" /inheritance:r /grant ""Administrators:F"" /grant ""SYSTEM:F"""
ssh username@domain@hostname $remotePowershell重要なのは、公開鍵を置くだけでなくACLを適切に設定することです。administrators_authorized_keys は、基本的にAdministratorsとSYSTEMだけがアクセスできる状態にする必要があります。
日本語版Windows Serverなど、英語以外のローカライズ環境では、グループ名の扱いで失敗することがあります。その場合は、グループ名ではなくSIDを使う方が安全です。
AdministratorsグループのSIDを使う例は次のとおりです。
$remotePowershell = "powershell Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value '$authorizedKey';icacls.exe ""$env:ProgramData\ssh\administrators_authorized_keys"" /inheritance:r /grant ""*S-1-5-32-544:F"" /grant ""SYSTEM:F"""*S-1-5-32-544 は組み込みAdministratorsグループを指すSIDです。ローカライズされたグループ名でスクリプトが失敗する場合は、このSID形式を検討してください。
ssh-agentを使う理由と注意点
秘密鍵はパスワードと同じ扱いで保護する必要があります。Windowsでは ssh-agent を使うことで、秘密鍵をWindowsアカウントに関連付いたセキュリティコンテキスト内に保持できます。(Microsoft Learn)
ssh-agent を自動起動し、秘密鍵を登録する例は次のとおりです。
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ecdsassh-agent に鍵を登録すると、SSHクライアントは必要に応じて秘密鍵を利用できます。毎回秘密鍵ファイルのパスを指定する手間を減らせるため、管理端末から複数のWindows Serverへ接続する運用では便利です。
ただし、Microsoft Learnでは、秘密鍵を安全な場所へバックアップしたうえで、ssh-agent へ追加後にローカルシステム上の秘密鍵を削除することも推奨しています。秘密鍵を失うと、エージェントから取り出せない場合があり、接続先すべてで公開鍵を更新する必要があります。(Microsoft Learn)
実務では、次の3点を運用ルールに入れてください。
| 項目 | 推奨対応 |
|---|---|
| 秘密鍵の保管 | 暗号化された安全な場所にバックアップする |
| パスフレーズ | 空にせず、端末紛失時のリスクを下げる |
| 鍵の棚卸し | 退職者、異動者、廃止端末の公開鍵を定期的に削除する |
Microsoft Entra IDアカウントでは鍵認証できない点に注意
現在のMicrosoft Learnでは、OpenSSH for Windowsのキーベース認証はローカルWindowsアカウントとActive Directoryドメインアカウントで機能し、Microsoft Entra IDアカウントではサポートされないと明記されています。(Microsoft Learn)
これは、クラウドID中心の環境では見落としやすいポイントです。
たとえば、次のような構成では事前確認が必要です。
| 構成 | 注意点 |
|---|---|
| Entra ID参加のみの管理端末からWindows ServerへSSH | サーバー側のログインアカウントとしてEntra IDをそのまま使えない |
| Azure上のWindows ServerをOpenSSHで管理 | ローカル管理者、ADドメインアカウント、別の認証経路を設計する |
| ID管理をEntra IDに一本化したい | OpenSSH鍵認証だけで要件を満たせるか確認が必要 |
「クラウドIDでWindowsへサインインできるから、OpenSSHの公開鍵認証でも同じアカウントを使える」と考えると設計ミスになります。Windows ServerのSSH運用では、どのアカウント体系でログインさせるのかを先に決めてください。
AuthorizedKeysCommandはWindows OpenSSHで使えない
LinuxのOpenSSH運用に慣れている管理者は、AuthorizedKeysCommand を使ってLDAPやディレクトリサービスから公開鍵を動的に取得する構成を想定することがあります。
しかし、Windows OpenSSHでは AuthorizedKeysCommand と AuthorizedKeysCommandUser はサポートされていません。Microsoft LearnのOpenSSH Server構成ページでも、Windows版OpenSSHに含まれるバージョンでは利用できない構成引数として挙げられています。(Microsoft Learn)
つまり、Windows Serverで公開鍵を集中管理したい場合は、次のような別の運用を考える必要があります。
| やりたいこと | 現実的な対応 |
|---|---|
| ユーザーごとの公開鍵を集中配布したい | PowerShell、構成管理ツール、GPO、運用スクリプトでファイル配布する |
| ADから動的に公開鍵を取得したい | Windows OpenSSH標準の AuthorizedKeysCommand では実現できない |
| 管理者の公開鍵を統制したい | administrators_authorized_keys を管理対象ファイルとして扱う |
| 鍵の失効を即時反映したい | 公開鍵ファイルの更新と sshd の挙動確認を運用手順に入れる |
Linuxと同じ設計をそのままWindows Serverに移植するのではなく、Windows版OpenSSHでサポートされる構成を前提に設計することが重要です。
鍵認証セッションではアウトバウンド認証に注意
Microsoft Learnでは、鍵認証で開いたリモートセッションには関連付けられたユーザー資格情報がなく、そのセッションからユーザーとしてアウトバウンド認証できないと説明されています。これは仕様です。(Microsoft Learn)
この点は、管理作業の自動化で特に重要です。
たとえば、SSHでWindows Serverへログインしたあとに次の操作を行う場合、想定どおりに動かないことがあります。
- 別サーバーの共有フォルダーへアクセスする
- ドメイン上の別リソースへユーザー資格情報で接続する
- SQL Serverや管理サーバーへ現在のユーザーとして接続する
- リモート先からさらに別のWindows Serverへ操作を中継する
これは、いわゆる「二段目の認証」で問題になりやすい部分です。鍵認証は初回ログインには有効ですが、その先のリソースアクセスまで自動的に保証するものではありません。
運用設計では、次のように切り分けて考えると安全です。
| 用途 | 鍵認証との相性 |
|---|---|
| サーバーへの初回SSHログイン | 相性が良い |
| SFTP/SCPによるファイル配置 | 相性が良い |
| ローカルサービスの再起動 | 相性が良い |
| 別サーバーへのドメイン資格情報アクセス | 追加設計が必要 |
| 多段SSHや横展開の管理作業 | 認証方式と権限委任の確認が必要 |
Windows ServerでOpenSSH鍵認証を導入する実務手順
ここからは、実際に導入するときの流れを整理します。
OpenSSH Serverが導入済みか確認する
Windows Server 2025ではOpenSSHが既定でインストールされると説明されていますが、sshd サービスが有効化されているかは別途確認が必要です。Windows Server 2019や2022では、環境によってOpenSSH Serverの追加が必要です。(Microsoft Learn)
管理者権限のPowerShellで確認します。
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'未導入の場合は、OpenSSH Serverを追加します。
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0サービスを起動し、自動起動に設定します。
Start-Service sshd
Set-Service -Name sshd -StartupType Automaticファイアウォールルールも確認します。
Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinueルールがない場合は、TCP 22番を許可する必要があります。OpenSSH Serverのインストール時に自動作成されることがありますが、セキュリティポリシーやイメージ作成手順によっては無効化されている場合があります。
先にパスワード認証で接続できるか確認する
公開鍵を配置する前に、対象ユーザーでSSHログインできるか確認します。
ssh username@hostnameドメインユーザーの場合は、環境に応じて次のような形式を試します。
ssh domain\username@hostnameまたはUPN形式を使います。
ssh [email protected]@hostnameここで接続できない場合、公開鍵認証以前の問題です。DNS、ファイアウォール、sshd サービス、ユーザー権限、OpenSSH Usersグループ、アカウント表記を確認してください。
公開鍵を配置する
対象ユーザーが標準ユーザーか管理者かを確認し、配置先を選びます。
標準ユーザーなら次のファイルです。
C:\Users\username\.ssh\authorized_keys管理者ユーザーなら次のファイルです。
C:\ProgramData\ssh\administrators_authorized_keysこの判断を間違えると、公開鍵の内容が正しくても認証に失敗します。特に、日常的に管理者権限で作業しているアカウントは administrators_authorized_keys 側を確認してください。
鍵認証で接続テストする
秘密鍵を明示して接続する場合は、次のように指定できます。
ssh -i $env:USERPROFILE\.ssh\id_ecdsa username@hostname詳細ログを見たい場合は、-v を付けます。原因調査では -vvv まで上げることもあります。
ssh -vvv -i $env:USERPROFILE\.ssh\id_ecdsa username@hostname接続できたら、必要に応じて ssh-agent に秘密鍵を登録します。
ssh-add $env:USERPROFILE\.ssh\id_ecdsaよくある失敗と切り分け方法
Windows ServerのOpenSSH鍵認証では、エラー原因が「鍵そのもの」ではないことがよくあります。次の表で切り分けると、無駄な再設定を減らせます。
| 症状 | よくある原因 | 確認ポイント |
|---|---|---|
| パスワード認証は通るが鍵認証が通らない | 公開鍵の配置先が違う | 標準ユーザーか管理者ユーザーか確認 |
| 管理者アカウントだけ鍵認証に失敗する | authorized_keys に置いている | C:\ProgramData\ssh\administrators_authorized_keys を使う |
administrators_authorized_keys を作ったが失敗する | ACLが広すぎる、または不正 | AdministratorsとSYSTEMの権限を確認 |
| 日本語版WindowsでACL設定が失敗する | グループ名のローカライズ | *S-1-5-32-544 のSID指定を使う |
| サンプルコマンドを貼ったが接続できない | username@domain@hostname の置換ミス | ログイン名とホスト名を分けて確認 |
| Entra IDユーザーでログインできない | 鍵認証がサポート対象外 | ローカルアカウントまたはADアカウントで再設計 |
| SSHログイン後に別サーバーへアクセスできない | 鍵認証セッションにユーザー資格情報がない | 二段目の認証方式を別途設計 |
sshd_config を変えても反映されない | サービス再起動をしていない | Restart-Service sshd を実行 |
sshd_config の変更は、サービス再起動後に反映されます。設定を変えたのに挙動が変わらない場合は、まず sshd の再起動を確認してください。(Microsoft Learn)
Restart-Service sshdセキュリティを高めるための運用チェックリスト
鍵認証を導入しても、秘密鍵の管理が甘ければ安全とは言えません。Windows ServerでOpenSSHを継続運用するなら、次の項目をチェックしてください。
| チェック項目 | 判断基準 |
|---|---|
| 秘密鍵にパスフレーズを設定しているか | 管理端末の紛失やマルウェア感染時の被害を抑えられる |
| 秘密鍵を共有していないか | 個人ごとに鍵を発行し、共有鍵を避ける |
| 退職・異動時に公開鍵を削除しているか | authorized_keys と administrators_authorized_keys を棚卸しする |
| 管理者用公開鍵ファイルのACLが適切か | SYSTEMとAdministrators以外に不要な権限がない |
| パスワード認証を残す理由が明確か | 鍵認証移行後、不要なら無効化を検討する |
| 緊急時の代替ログイン経路があるか | RDP、コンソール、Break Glassアカウントを用意する |
| ログを確認できるか | トラブル時に認証失敗の原因を追える状態にする |
パスワード認証を無効化する場合は、必ず別セッションで鍵認証の成功を確認してから実施してください。いきなり無効化すると、設定ミスで自分自身を締め出す可能性があります。
2026年4月更新を受けて社内手順書で直すべき箇所
今回の更新は、社内Wikiや運用手順書に反映する価値があります。特に、過去にMicrosoft Learnの古いサンプルをコピーして作った手順がある場合は、次の項目を見直してください。
| 見直し対象 | 修正ポイント |
|---|---|
| 公開鍵展開コマンド | 接続文字列を username@domain@hostname の考え方で説明する |
| 管理者向けPowerShell例 | 古い三重引用符の例が残っていないか確認する |
| 管理者ユーザーの配置先 | administrators_authorized_keys を明記する |
| 標準ユーザーの配置先 | authorized_keys のファイル名を正確に書く |
| 日本語版Windows向け手順 | Administratorsグループ名ではなくSID例も併記する |
| Entra ID環境向け注意 | Entra IDアカウントは鍵認証非対応と明記する |
| トラブルシュート | 「配置先」「ACL」「接続文字列」を最初に確認する流れにする |
特に重要なのは、管理者アカウントの扱いです。Windows Serverでは管理者権限でSSH接続するケースが多いため、authorized_keys ではなく administrators_authorized_keys を使うことを手順の最初に書いておくと、問い合わせや切り分け時間を減らせます。
Windows ServerのOpenSSH鍵認証は「設定」より「運用設計」が重要
Key-Based Authentication in OpenSSH for Windowsは、Windows Serverのリモート管理やSFTP連携を安全にするうえで有効な選択肢です。ただし、Linuxと同じ感覚で設定すると、管理者ユーザーの公開鍵配置先、ACL、Entra ID非対応、アウトバウンド認証の制約でつまずきます。
2026年4月の更新では、接続文字列とPowerShell例がより実務向けに整理されました。まずは自社の手順書で、次の3点を確認してください。
- 管理者ユーザーは
C:\ProgramData\ssh\administrators_authorized_keysを使う - 公開鍵展開コマンドの
username、domain、hostnameの置き換え方を明記する - Entra IDアカウントではOpenSSH for Windowsの鍵認証が使えないことを設計段階で確認する
既存のWindows ServerでOpenSSHを使っている場合は、まずテスト用ユーザーで鍵認証を再確認し、その後に管理者アカウント、ACL、秘密鍵管理、パスワード認証の扱いを順番に見直すのが安全です。
コメント