Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

sshd leaks an LSA logon session (sshd_<pid> virtual account), lsass handles and nonpaged pool on every connection, never released until reboot

オープン
  • 何か問題がありますか？
#2,476 コメント 0 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c
領域
backend, security

調査の方向性

Start by reproducing the leak with the PowerShell steps in the issue and compare logon session, LSASS handle, and nonpaged pool counts before and after connections close. Trace the per-connection child (sshd-session/sshd_<pid>) lifecycle and its LSA logon session cleanup. Done means those resources return to baseline after both pre-authentication and authenticated connections close.

索引モデルが issue の本文から書いたものです。

説明

Prerequisites
  • Write a descriptive title.
  • Make sure you are able to repro it on the latest version
  • Search the existing issues.

"OpenSSH for Windows" version

  • 10.0.0.0 (Microsoft.OpenSSH.Preview via winget, OpenSSH_10.0p2), reproduced
  • 9.5.6.4 (inbox optional feature, OpenSSH_9.5p2), reproduced

Server OperatingSystem
Windows 11 Pro 25H2 (10.0.26200), default sshd_config

Client OperatingSystem
Any. Reproduced locally with ssh-keyscan (Windows); seen in the wild from a Linux monitoring tool (Termix host status check) and from OpenSSH 10.3p1 clients (Alpine/macOS).

What is failing

Every incoming connection that reaches key exchange leaks one LSA logon session (the VIRTUAL USERS\sshd_<pid> privilege-separation account, LogonType 5) plus ~3 handles in lsass.exe and ~50 KB of nonpaged pool. They are never released after the connection closes, whether it closes [preauth] or after a successful login. Only a reboot frees them.

Authenticated connections additionally leak a LogonType 3 (Network) session for the target user.

On a machine that is simply health-checked or polled over SSH, this grows without bound. In my case, after 6 days of uptime:

  • Win32_LogonSession count: 51,080 (normal: ~100). ~36k LogonType 5 (sshd_* virtual users, most with the account already deleted) and ~15k LogonType 3 (NTLM) for the user that logged in
  • lsass.exe handles: 155,000 (normal: ~2,000)
  • Nonpaged pool: 4.2 GB, paged pool: 3.1 GB
  • ~25 GB of RAM in use that does not belong to any process (47 GB machine, processes summing ~20 GB)

The traffic was a monitoring tool opening one connection every ~5 s. After reducing it, the leak continued at the rate of a TCP/SSH status check every ~33 s (connect → KEX → close [preauth]): +3,000 logon sessions in 2 days.

Note: a connection that only reads the server banner and closes does not leak. The leak starts once sshd spawns the per-connection (sshd-session/sshd_<pid> virtual account) child.

Steps to reproduce (elevated PowerShell)

$ks = "C:\Program Files\OpenSSH\ssh-keyscan.exe"   # or any ssh-keyscan
$s0 = (Get-CimInstance Win32_LogonSession).Count
$h0 = (Get-Process lsass).Handles
$n0 = (Get-CimInstance Win32_PerfRawData_PerfOS_Memory).PoolNonpagedBytes

1..50 | % { & $ks -t ed25519 127.0.0.1 | Out-Null }
Start-Sleep 5

$s1 = (Get-CimInstance Win32_LogonSession).Count
$h1 = (Get-Process lsass).Handles
$n1 = (Get-CimInstance Win32_PerfRawData_PerfOS_Memory).PoolNonpagedBytes
"Logon sessions +$($s1-$s0) | lsass handles +$($h1-$h0) | nonpaged +$([math]::Round(($n1-$n0)/1MB,1)) MB"

# Leaked sessions: LogonType 5, Negotiate, most with no resolvable account
Get-CimInstance Win32_LogonSession | Group-Object LogonType, AuthenticationPackage | Select Count, Name

Expected output

Logon sessions, lsass handles and nonpaged pool return to baseline once the connections are closed.

Actual output

OpenSSH_9.5p2 (inbox), 50 probes:

Logon sessions +51 | lsass handles +152 | nonpaged +2.5 MB

OpenSSH_10.0p2 (Preview, run as a separate LocalSystem service on port 2222), 50 probes, 21 completed (the rest were throttled by PerSourcePenalties):

Logon sessions +22 | lsass handles +60 | nonpaged +2.9 MB

i.e. one leaked logon session per completed connection. The values never go back down; Security log shows a 4624 (LogonType 5, VIRTUAL USERS\sshd_<pid>, process sshd.exe) for each connection with no matching 4634 logoff.

Impact

Any client that can reach port 22 can grow kernel memory and lsass without authenticating, so the server eventually runs out of memory. Monitoring/health checks and automation that open frequent short SSH connections (Ansible, uptime monitors, scripts not using ControlMaster) trigger it in normal use.

Workarounds I'm using: multiplex client connections (ControlMaster/ControlPersist), lower the frequency of health checks, reboot periodically.

主要言語
言語のデータがありません
スター
8.3k
フォーク
822
平均マージ
7分
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

PowerShell/Win32-OpenSSH のほかの issue

PowerShell/Win32-OpenSSH の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。