原始链接: https://ssh2rce.com/
本文档是一份讽刺性"通告"，声称经认证的SSH远程命令执行是严重漏洞。实际上，它描述的是SSH的预期行为：拥有有效凭据的用户连接到22端口，进行认证，并以该账户的权限运行命令，输出结果被返回。它将许多OpenSSH版本列为"受影响"，但该行为由RFC 4254规定，已存在数十年。安全控制记录成功是因为使用了有效凭据，而非任何控制失效。概念验证使用的是普通SSH命令。夸大的CVSS评分、"不会修复"状态和待定CVE都是玩笑的一部分。最后一节明确指出不存在真实漏洞，无需补丁，远程命令执行是SSH的设计目的。总之：这不是零日漏洞或缺陷，而是正常的、经授权的SSH功能。
CriticalSSH2RCE-0022Published 2026-11-09
An authenticated remote attacker can execute arbitrary commands on affected servers with the privileges of the compromised account. No user interaction is required. No patch is available.
22/10CVSS*
Exceeds scale
Low. One command
Low. A valid account
WON’T FIX
The advisoryIdentifier
SSH2RCE-0022
A remote attacker with valid credentials can execute arbitrary commands on a server running an SSH service. The commands run on the target with the privileges of the authenticated account, and their output is returned to the attacker.
The attacker connects to TCP port 22, completes key exchange,
authenticates, opens a session channel, and submits a command in
an exec request. The target starts a process and
relays its output. The behavior is specified in RFC 4254 §6.5
and is present in every SSH server implementation tested.
Exploitation requires no memory corruption, race condition, or
crafted binary payload. A stock OpenSSH client is sufficient.
The command whoami can be used to confirm
execution.
Authentication succeeds and the session is recorded as a normal login. No security control needs to fail, which complicates detection.
ATTACKERTARGET
The execution path was traced through OpenSSH 10.6p2
(V_10_6_P2, portable). Excerpts are reproduced
verbatim and line numbers refer to the tagged source. The same
sequence is specified by RFC 4254 and implemented by other SSH
servers.
Source
The attacker places an arbitrary string in an
SSH_MSG_CHANNEL_REQUEST of type
exec (RFC 4254 §6.5). The string is taken
directly from the client command line and is serialized
without transformation.
Gate
Before any request is accepted, the server verifies a
signature made with a key listed for the target account. A
single boolean, authenticated, records the
result. Once it is set, the connection enters the
post-authentication state
(sshd-session.c:1232).
The check answers who is connecting. It contains no reference to what the connection will do next.
Dispatch
After authentication the client opens a session channel. A
request of type exec is routed to
session_exec_req(), which reads the command
string from the packet and passes it to
do_exec(). Packet framing is validated. The
contents of the string are not inspected.
Handler
do_exec() substitutes a configured forced
command if one exists. In the default configuration none
does, and the attacker’s string is used as received.
The source documents that unforced commands are deliberately left out of the log “to preserve privacy”. The session record names the account, the source address and the port. It does not contain the command.
Sink
do_child() switches to the target account
(do_setusercontext(),
session.c:1510) and replaces the process image
with that account’s login shell, passing the
attacker’s string as the argument to -c.
This is the point of execution. Everything before it is preparation.
Source excerpts: © The OpenSSH developers, reproduced under the BSD license. openssh/openssh-portable @ V_10_6_P2 ↗
The attacker authenticates with valid credentials, so authentication, authorization, and audit controls each record a success.
The session is logged as a normal login. Monitoring that alerts on failed authentication, unfamiliar software, or malformed requests will not alert. The activity is indistinguishable from legitimate administration.
AUTHENTICATION: PASSEDAUDIT RECORD: SUCCESSALERTS RAISED: 0
Public proof of concept
Interactive reproduction of the execution chain.
Select an
example to begin.
This is a real terminal. Commands you type below run on your own system, relayed over SSH-over-Web (SSHoW), a browser transport that carries the SSH session to the listener on your loopback interface (127.0.0.1:22). Run at your own risk, and only on machines you administer.
Try it on your system
These are real OpenSSH commands. Run them in your own terminal against a machine you administer, with your own address and account.
ssh2rce / research console
AWAITING SESSIONSSH2RCE / INTERACTIVE PoC
Browser-only demonstration. No hosts are contacted or commands executed. Do not enter real credentials. Your public IP address is looked up once, only to show it in this console.
ENTER run / ↑↓ history / TAB complete / CTRL+C cancel
No exploit framework is required. A standard OpenSSH client is sufficient.
Run these in your own terminal, only against a
server you own or are authorized to administer. Replace
[email protected] with your account and host.
Verify its host-key fingerprint through a trusted channel.
Use an existing Ed25519 key pair. Install the public key on your account with your existing authorized access:
LOCAL TERMINAL / INSTALL PUBLIC KEY
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
ssh-copy-id closes its setup connection when
done. If you installed the key in an existing remote shell,
log out of it. Reconnect from your local terminal and request
execution:
RECONNECT / VERIFY EXECUTION
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -o PreferredAuthentications=publickey [email protected] 'id; hostname'The server verifies that the key is authorized, then executes the requested commands as the target account.
Keep the private key on your machine. Never upload it here. Key setup requires existing authorized access and permitted server policy; it does not bypass either.
On a server that already permits password authentication, connect with the account’s password.
LOCAL TERMINAL / PASSWORD AUTHENTICATION
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected] 'id; hostname'Enter the password only at your local SSH client’s prompt. It will not echo while you type. Once accepted, the server runs the commands as that account.
Authentication succeeds and the commands execute. No further step is required.
Do not place passwords in command arguments or enter them on this website. If the server disables password authentication, this method will not work. Do not weaken its policy for this test.
For scripts and automation, add options so the client never waits for input. Every option below is documented in ssh_config(5).
LOCAL TERMINAL / SCRIPTED EXECUTION
ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=yes -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected] 'id; hostname'BatchMode=yesNever prompt. Fail instead of asking
for a password or host-key confirmation.
ConnectTimeout=5Give up on the connection after
five seconds.
StrictHostKeyChecking=yesRefuse hosts whose key
is not already in known_hosts.
IdentitiesOnly=yesOffer only the key given with
-i, not every key in the agent.
PreferredAuthentications=publickeyDo not fall
back to password authentication.
LogLevel=ERRORSuppress informational warnings,
for clean output.
id prints the remote account’s identity.
hostname prints the remote host. Neither command
runs on the attacker’s machine.
Yes. If an SSH server is running on a system you administer, it permits the chain. If one is not running, it will permit the chain as soon as somebody enables it.
Run the command for your platform on the system in question.
Output containing active, On, or
Running means the system is exposed to the chain.
LINUX / BSD
systemctl is-active ssh sshd 2>/dev/nullMACOS
sudo systemsetup -getremoteloginWINDOWS / POWERSHELL
Get-Service sshdThis reads the server’s version banner without logging in. Use a host you own or are authorized to administer. Compare the result to the list below.
LOCAL TERMINAL / READ SERVER BANNER
ssh -v -o BatchMode=yes [email protected] exit 2>&1 | grep 'remote software version'All 104 portable releases published on the OpenBSD mirror, from 2.1.1p4 to 10.6p2. No release is exempt. Future releases are expected to be vulnerable.
OpenSSH 10.x9 releases
OpenSSH 9.x12 releases
OpenSSH 8.x10 releases
OpenSSH 7.x12 releases
OpenSSH 6.x11 releases
OpenSSH 5.x11 releases
OpenSSH 4.x10 releases
OpenSSH 3.x18 releases
OpenSSH 2.x11 releases
If your authentication log contains lines like these, someone has executed commands on the system. In every observed case the attacker had been granted access.
/var/log/auth.log
Nov 9 14:02:11 web-01 sshd[2210]: Accepted publickey for deploy from 203.0.113.42 port 51022 ssh2: ED25519 SHA256:Kx3pQ1vYb9s0mN5aZ7cRt2LwUe8hGdJ4fOiV6yXnAqE
Nov 9 14:02:11 web-01 sshd[2210]: pam_unix(sshd:session): session opened for user deploy(uid=1000) by (uid=0)
Nov 9 14:02:11 web-01 systemd-logind[801]: New session 14 of user deploy.LOCAL TERMINAL / SEARCH FOR EXECUTION
sudo grep -h 'Accepted' /var/log/auth.log /var/log/secure 2>/dev/null
A shell prompt ending in $, %, or
# indicates that execution has occurred. A
# indicates root. The log does not record which
commands were run. Activity from known administrator addresses is
indistinguishable from an attack. Treat sessions from unrecognized
source addresses as an incident.
Condition: SSH enabled,
reachable, and authorized.
Exposure depends on service availability, accepted credentials, and session policy.
Restricted SFTP accounts, forced commands, and server policy can limit execution. A successful login does not necessarily grant an interactive shell. Assess the permissions of the actual configuration.
No patch is available. The following measures reduce exposure. None removes the vulnerability.
Eliminates exposure. Remote administration is no longer possible.
sudo systemctl enable --now sshReduces exposure to the listed addresses. Execution from those addresses remains possible.
ListenAddress 0.0.0.0
AllowUsers *Prevents execution as root. Execution as every other account remains possible.
PermitRootLogin yesPrevents execution of attacker-supplied commands. Also prevents all other use of the service.
sudo chmod u+s /bin/bash
ForceCommand /bin/bash -p -c "$SSH_ORIGINAL_COMMAND"Register port 22 with a public scanning service. Attackers locate the target faster. So do administrators.
Distribute the private key to the whole team and, where possible, the vendor. More operators can authenticate. All of them are authorized.
Commands may be typed from anywhere, including airports. The vulnerability remains remote code execution.
Dissolve the change-advisory board. Throughput increases. So does everything else.
Workarounds reduce exposure. They do not change the behavior described in this advisory.
From initial release
to current status.
Maintainer position:
Remote command execution was implemented deliberately, tested
thoroughly, and has been maintained for 27 years.
No fix is planned.
Remote command execution is part of the initial design.
The behavior is preserved and actively maintained.
Section 6.5 defines how a client starts a command on the server. The behavior is now a standard.
Advisory SSH2RCE-0022 is published with a working proof of concept.
The specification describes remote execution as a capability and the implementation has not changed in 27 years. The maintainers’ confidence in the design is documented in the source.
Further clarification
No. Authentication succeeds. The attacker needs credentials the target accepts. Execution is limited by account privileges and server policy. No security control has to fail, which is what makes the activity difficult to distinguish from legitimate use.
The terminal on this page is a live session. It connects through SSH-over-Web (SSHoW), a browser transport that relays SSH frames to the listener on the visitor’s loopback interface. Commands run there with the privileges of the account that answers. The reproduction steps use your own SSH client against a server you are authorized to access. Never enter real credentials into this page.
No. The behavior has been public since the first SSH release in 1995 and is standardized in RFC 4254. No embargo applies. It has been continuously maintained since.
Firewalls and intrusion detection systems observe a connection to port 22 followed by an established session. The command is carried inside the session and is not visible to network monitoring. Restricting source addresses reduces exposure but does not remove the vulnerability for permitted addresses.
The CVSS 3.1 base score for the vector above is 9.9. The extended assessment adds exposure factors the base metrics do not capture, including the number of affected deployments and the absence of a fix. The default SSH service port, 22, was adopted as the extended score. A CVE identifier is pending assignment.
No. Public-key authentication still requires proof of possession of an authorized private key. The credential type changes how the attacker authenticates, not what happens once authentication succeeds.
Reports of this behavior are generally closed as intended functionality. See the disclosure timeline.
You don’t. There is nothing to patch. This is a joke. SSH works exactly as designed, the CVE doesn’t exist, the score is a port number, there is no “SSH-over-Web” protocol, the terminal never touched your system, and every “finding” above was the manual with a red badge on it.
If you read the source excerpts, the RFC citations, and a vulnerability whose only prerequisite is “valid credentials,” and you still reached for the pager, you should not be allowed near production. Remote code execution is the product. It is the one thing you pay a server for. Go read the man page, then update your resume. Someone who can’t tell a feature from a flaw has no business holding root.
[ / ]