T09 · Insecure Skill Coding Practices
- Location
SKILL.md:62- Finding
SSH Host Key Verification Is Explicitly Disabled
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 62
Vulnerability Type: SSH host impersonation and man-in-the-middle exposure
Risk Level: HighVulnerable code snippet:
bash ssh -o StrictHostKeyChecking=no user@your-server-ipTechnical Analysis
The documented SSH command sets
StrictHostKeyChecking=no. This causes the SSH client to accept an unrecognized host key without requiring the user to verify its fingerprint.SSH host-key validation authenticates the remote server before credentials or commands are exchanged. Disabling strict validation removes this protection for first-time or otherwise untrusted connections. An attacker capable of redirecting network traffic can present an attacker-controlled SSH server, and the client will proceed without warning the user that the server identity has not been verified.
Although SSH still encrypts the transport, that encryption terminates at the attacker's impersonating server. If password authentication is used as recommended elsewhere in the documentation, the user may disclose the server password to the attacker. The attacker can also display fabricated command output or proxy the session to the legitimate server.
Attack Path
- A user follows the documented command to connect to a server.
- An attacker gains a traffic-redirection position through a compromised gateway, rogue wireless network, DNS poisoning, routing manipulation, or modification of the destination IP.
- The attacker operates an SSH server and presents an arbitrary host key.
- Because
StrictHostKeyChecking=nois enabled, the client accepts the unverified key without requiring fingerprint confirmation. - The user authenticates to the impersonating server.
- With password authentication, the attacker-controlled endpoint can capture the submitted password.
- The attacker may use the captured credentials against the legitimate server, subject to network reachabili ...[truncated 964 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove the option that disables host-key verification:
bash ssh user@your-server-ip -
Before the first connection, obtain the server's SSH host-key fingerprint through a trusted, independent channel such as the cloud provider console or an authenticated administrator.
-
Compare the displayed fingerprint with the trusted fingerprint before accepting and storing the key.
-
For automated use, provision a verified host key in
known_hostsand require strict checking:bash ssh -o StrictHostKeyChecking=yes user@your-server-ip -
Do not rely on unauthenticated
ssh-keyscanoutput alone. If it is used to collect a key, verify the resulting fingerprint independently before trusting it. -
Prefer SSH public-key authentication, disable password authentication where operationally possible, avoid direct root login, and grant only the minimum required permissions.
-
Update all documentation and examples so they never recommend bypassing SSH server identity verification.
-
