sshd leaks an LSA logon session (sshd_<pid> virtual account), lsass handles and nonpaged pool on every connection, never released until reboot
还没有人认领这个 Issue。
评估
调研方向
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.Previewvia 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_LogonSessioncount: 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 inlsass.exehandles: 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
- 平均合并
- 9 分钟
- 30 天内合并 PR
- 2
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
PowerShell/Win32-OpenSSH 的其他 Issue
-
Area-ssh-agent Issue-Upstream Parity
难度 2/5 1-3 小时 新手友好度 74/100
PowerShell/Win32-OpenSSH#2458 · 1 条评论 · 1 个 reaction ·
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 54/100
PowerShell/Win32-OpenSSH#2477 ·
-
10.4.0.0p1-Preview: SSH sessions no longer get the user's PATH (HKCU\Environment), only the machine PATH可能已有人在做 @tgauth 于 1 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 57/100
PowerShell/Win32-OpenSSH#2474 · 3 条评论 · 1 个 reaction ·
-
难度 4/5 3-5 天 新手友好度 48/100
PowerShell/Win32-OpenSSH#2472 · 1 条评论 · 1 个 reaction ·
-
0 - Backlog Area-sshd Area-Terminal Investigate Issue-Bug
难度 4/5 3-5 天 新手友好度 48/100
PowerShell/Win32-OpenSSH#2468 · 4 条评论 · 1 个 reaction ·
查看 PowerShell/Win32-OpenSSH 的全部 Issue
相似的 Issue
-
needs-triage
难度 2/5 1-3 小时 新手友好度 78/100
11ty/buildawesome#4407 · 1 个 reaction ·
维护者通常 1 天内回复
-
area: image-engine bug priority: low
难度 2/5 1-3 小时 新手友好度 88/100
snapotter-hq/SnapOtter#3885 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
keyxmakerx/Chronicle#1721 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
Gentleman-Programming/gentle-ai#5720 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复