WindowsでOpenSSH Serverサービスが開始できない原因と対処｜sshdの権限・設定・更新を確認

WindowsでOpenSSH Serverサービスが開始できないときは、まず再インストールに走るより、C:\ProgramData\ssh の権限、sshd_config の整合性、更新や旧版混在の影響を順番に切り分けるのが近道です。特に多いのは、更新後に C:\ProgramData\ssh 配下のACLが崩れるケースと、sshd_config をLinux向け設定のまま流用して失敗するケースです。この記事では、最短の確認順、よくある原因、復旧手順、再発しにくい戻し方まで、実務でそのまま使える形で整理します。 (Microsoft Learn)

「サービスが開始できない」のか、「サービスは開始しているが接続できない」のかを分けて考えるのも重要です。前者は設定ファイルや権限の問題が中心で、後者はポート22の待ち受け、ファイアウォール、ポート競合、接続許可グループなどを確認します。ここを混同すると、原因を外したまま設定を壊しやすくなります。 (Microsoft Learn)

WindowsでOpenSSH Serverサービスが開始できないときの最短切り分け

最初の5分は、インストール有無→サービス状態→設定検証→ログ→ポート待ち受けの順で確認すると効率的です。Windowsの追加機能版では Get-WindowsCapability と Get-Service、設定検証は sshd -t、ログは OpenSSH のイベントログ、接続系はポート22の待ち受け確認が基本になります。 sshd -t は OpenSSH 本家でも、設定ファイルの妥当性と鍵の整合性を検査するためのモードです。 (Microsoft Learn)

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Get-Service sshd

# 追加機能版（既定）の確認
& "$env:WINDIR\System32\OpenSSH\sshd.exe" -t

# OpenSSH の直近ログを確認
Get-WinEvent -LogName "OpenSSH/Operational" -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

# ポート 22 の待ち受け確認
netstat -an | findstr :22

見方はシンプルです。OpenSSH.Server~~~~0.0.1.0 が NotPresent なら、まずインストールが必要です。Get-Service sshd が見つからない、または停止したままならサービス構成側の問題です。sshd -t が失敗するなら、sshd_config か鍵まわりの不整合を疑います。サービスが Running でも :22 が LISTENING でなければ、ポート設定、競合、ファイアウォールの切り分けに進みます。PowerShellで OpenSSH ログを見るときは、古い Get-EventLog より Get-WinEvent のほうが扱いやすいです。 (Microsoft Learn)

手動導入の GitHub 版を使っている場合は、sshd.exe が C:\Program Files\OpenSSH 系に入っていることがあります。Windows標準の追加機能版は通常 C:\Windows\System32\OpenSSH にあるため、sshd -t が通らないときはどの OpenSSH を使っているかも先に確認してください。混在していると、復旧しても別の実体を触っていることがあります。 (Microsoft Learn)

原因として最も多いのは C:\ProgramData\ssh の権限不整合

最近の代表例として、OpenSSH 9.5.2.1 に関連する一部のWindows更新後に、エラー 1053 / 1067 / Event ID 7034 で sshd が開始できなくなる問題が報告されています。Microsoftの案内では、原因は C:\ProgramData\ssh と C:\ProgramData\ssh\logs のアクセス権が狭すぎる場合も、広すぎる場合もあるとされていて、sshd_config を含めてACLの見直しが必要です。 (Microsoft Learn)

Get-Acl C:\ProgramData | Select-Object -Property AccessToString | Format-List
Get-Acl C:\ProgramData\ssh | Select-Object -Property AccessToString | Format-List
Get-Acl C:\ProgramData\ssh\logs | Select-Object -Property AccessToString | Format-List
Get-Acl "C:\ProgramData\ssh\sshd_config" | Select-Object -Property AccessToString | Format-List

見るポイントは2つだけです。SYSTEM と Administrators に必要な書き込み権があるか、そして一般ユーザーや Authenticated Users に書き込みやフルコントロールが残っていないかです。Microsoftはこの問題の回避として、2025年3月11日以降の更新では権限が不適切でもサービスを開始できる場合があると案内していますが、その場合でも Event ID 4 で権限のゆるさが記録されます。つまり、「起動したから安全」ではありません。ACL自体は直す前提で考えたほうが安全です。 (Microsoft Learn)

現場では、ここで Everyone や Users に広く権限を付けて無理やり通そうとするのが失敗パターンです。OpenSSH は緩すぎる権限も不正とみなすため、雑に権限を広げると逆効果になりやすいです。更新直後に急に起動しなくなったなら、まずここから見てください。 (Microsoft Learn)

sshd_config の誤りでサービスが開始できないケース

Windows版 OpenSSH は、既定で %ProgramData%\ssh\sshd_config を読みます。しかも、設定変更はサービス再起動まで反映されません。このため、設定を編集した直後に sshd が開始できなくなったなら、まず sshd_config を疑うのが正解です。なお、公式ドキュメントでは、設定ファイルが存在しない場合はサービス開始時に既定構成が生成されるとされています。 (Microsoft Learn)

特に注意したいのは、Linux向けの sshd_config をそのままコピーするパターンです。Windowsに同梱される版では、AuthorizedKeysCommand や AuthorizedKeysCommandUser、X11Forwarding など、そのまま使えないディレクティブがあります。さらに、接続側が22番を想定しているのに Port を変えていたり、HostKey を独自パスに向けていて実体がずれていたりすると、起動や待ち受けで詰まります。編集後は必ず sshd -t を通してください。 (Microsoft Learn)

notepad "$env:ProgramData\ssh\sshd_config"
& "$env:WINDIR\System32\OpenSSH\sshd.exe" -t
Start-Service sshd

「直前の編集からおかしくなった」なら、いったん設定を退避して既定生成に戻すほうが早いこともあります。sshd_config をバックアップ名に退避し、サービス開始時に既定ファイルを再生成させれば、設定由来の問題かどうかをかなり早く切り分けられます。カスタム設定は、既定で起動することを確認してから少しずつ戻すほうが安全です。 (Microsoft Learn)

Rename-Item "$env:ProgramData\ssh\sshd_config" "sshd_config.bak"
Start-Service sshd

エラー内容が薄いときはログを増やす

OpenSSH の既定ログだけでは原因が見えにくいことがあります。Microsoftは、詳細を追いたいときは sshd_config の Logging セクションを変更して、LogLevel VERBOSE を有効にする方法を案内しています。既定ではWindows Event Viewerに出ますが、SyslogFacility LOCAL0 にすると %ProgramData%\ssh\logs にファイルとして残せます。PowerShellでログを見るなら Get-WinEvent が便利です。 (Microsoft Learn)

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

ファイルで追いたいなら次のようにします。サービスを再起動してからログを見てください。 (Microsoft Learn)

# Logging
SyslogFacility LOCAL0
LogLevel VERBOSE

ホストキーと administrators_authorized_keys の権限も確認する

Windows の OpenSSH では、ホストキーは C:\ProgramData\ssh 配下に置かれ、初回の sshd 利用時に自動生成されます。Microsoftは、ホスト鍵や関連ファイルのACLは、実質的に管理者と SYSTEM のみが扱える状態にするよう案内しています。ここが崩れると、起動失敗や鍵関連エラーの原因になります。 (Microsoft Learn)

公開鍵認証まわりで誤解されやすいのは、管理者アカウントは通常の %UserProfile%\.ssh\authorized_keys ではなく、C:\ProgramData\ssh\administrators_authorized_keys を使うことです。このファイルも SYSTEM と Administrators だけの権限が前提です。管理者で鍵認証が通らないときは、サービスの起動失敗ではなく、このファイルの場所やACLを見直すほうが早いです。 (Microsoft Learn)

icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

標準ユーザーなら、既定の公開鍵ファイルは C:\Users\ユーザー名\.ssh\authorized_keys です。管理者だけ保存場所が違うので、ここを取り違えると「サービスは開始したのに鍵認証だけ失敗する」状態になりやすいです。 (Microsoft Learn)

更新後・旧版混在で壊れたときの復旧方針

OpenSSH には、Windowsの追加機能として入る同梱版と、GitHub から入れる Win32-OpenSSH 版があります。Microsoftの案内では、同梱版は通常 C:\Windows\System32\OpenSSH にあり、Windows Updateで更新されます。一方、GitHub版は C:\Program Files\OpenSSH 系に入り、より新しい修正を取り込みやすい反面、手動更新が必要です。ここを混在させると、古いフォルダやパス競合でトラブルが長引きます。 (Microsoft Learn)

Get-Command ssh.exe | Select-Object Source

過去に GitHub 版を手動導入し、その後 Windows の追加機能版を有効にした環境では、複数の OpenSSH フォルダが残っていないかを確認してください。公式のアップグレード手順でも、複数フォルダがある場合は新しいものを残して古いものを削除するよう案内しています。再インストールしても直らないときは、実は「別の OpenSSH 実体を触っていた」ことがよくあります。 (Microsoft Learn)

安定運用を優先するなら、まずは Windows Update 側で最新状態にそろえるのが無難です。逆に、同梱版が古くて既知の問題を踏んでいるなら、GitHub版へ統一する選択肢もあります。大事なのは、どちらか一方に寄せて混在を解消することです。 (Microsoft Learn)

サービス開始後に接続できない場合は別問題として切り分ける

OpenSSH Server をインストールすると、通常は OpenSSH-Server-In-TCP という受信ルールが作成され、ポート22を許可します。ここが無効だったり、ほかのポリシーやアプリが22番を使っていたりすると、サービスは生きているのに接続できない状態になります。Microsoftのトラブルシュートでも、ポート22の待ち受け、ファイアウォール、競合アプリ、NATや外部FWを分けて確認する流れを案内しています。 (Microsoft Learn)

Get-NetFirewallRule -DisplayName "*SSH*" |
  Get-NetFirewallPortFilter |
  Where-Object {$_.LocalPort -eq 22}

ssh localhost

ssh localhost が通るなら、少なくともローカルの sshd 自体は動いています。その場合はWindows Firewallやネットワーク機器、NAT、社内ポリシーの確認に進みます。逆に localhost でも失敗するなら、まだサーバー側の設定や権限に問題が残っています。イベントの確認先は Event Viewer > Applications and Services Logs > OpenSSH です。環境によっては、接続許可・制限に OpenSSH Users グループが使われることもあるので、サービス開始後に「一部ユーザーだけ入れない」ときはここも見ます。 (Microsoft Learn)

それでも直らないときの再インストール手順

ここまでで直らないなら、バックアップを取ってから追加機能版を入れ直すのが安全です。特に C:\ProgramData\ssh には sshd_config、administrators_authorized_keys、ホストキーが入るため、先に退避してください。ホストキーを不用意に変えると、クライアント側でホスト鍵の警告が出やすくなるので、何も考えず削除するのはおすすめしません。作業中にSSH接続が切れて困る環境では、RDPやコンソールなど代替経路を確保してから進めます。 (Microsoft Learn)

Copy-Item "C:\ProgramData\ssh" -Destination "C:\Backup\ssh_backup" -Recurse

Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Restart-Computer

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

if (!(Get-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -ErrorAction SilentlyContinue)) {
    New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' `
      -DisplayName 'OpenSSH Server (sshd)' `
      -Enabled True -Direction Inbound -Protocol TCP `
      -Action Allow -LocalPort 22
}

ssh localhost

この手順でも改善しないなら、旧版混在を疑ってください。追加機能版を入れ直しても C:\Program Files\OpenSSH 系の古い実体が残っていると、再発しやすいです。再インストールは最後の手段ですが、バックアップ付きで実行すれば復旧の失敗率をかなり下げられます。 (Microsoft Learn)

迷ったらこの順番で進めれば復旧しやすい

WindowsでOpenSSH Serverサービスが開始できないときは、①インストール有無の確認、②sshd -t、③C:\ProgramData\ssh のACL確認、④OpenSSHログ確認、⑤ポート22とファイアウォール確認、⑥最後にバックアップ付き再インストールの順で進めるのが最も無駄が少ないです。とくに、権限は「不足」だけでなく「広すぎる」ことでも失敗する点と、Linux向け設定の流用がWindows版でそのまま通るとは限らない点は、見落としやすいポイントです。まずは Get-Service sshd と sshd -t、次に C:\ProgramData\ssh を確認してください。そこが通れば、復旧はかなり近いです。 (Microsoft Learn)