SSH Essentials (Security Remediation)

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:46 AM UTC
• Version: 2.0.0

Overview

This is a coherent SSH reference skill, but some copyable examples could weaken SSH host verification or mislead users about connection encryption.

Install only if you want a general SSH command reference and are comfortable vetting commands before use. Treat StrictHostKeyChecking=no, ssh-keyscan >> known_hosts, rsync --delete, agent forwarding, remote forwarding, background tunnels, and sudo-over-SSH as sensitive operations that should be adjusted to your environment and run only after you understand the consequences.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:246
• Finding: Host-Key Verification Disabled in SSH Configuration Example<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 246–247 **Vulnerability Type**: Unsafe SSH host-key verification configuration **Risk Level**: High ### Vulnerable Code ```bash # Override config options ssh -o "StrictHostKeyChecking=no" myserver ``` ### Technical Analysis The example disables SSH host-key verification without an adjacent warning or safer alternative. `StrictHostKeyChecking=no` allows SSH to continue when the presented host key has not been independently trusted. Depending on other SSH options and existing `known_hosts` state, it can also permit connections despite host-key inconsistencies. Host-key verification is the principal SSH control that authenticates the remote server. Disabling it weakens protection against DNS spoofing, malicious network gateways, compromised routing infrastructure, and man-in-the-middle attacks. Although other sections of the document warn against this option, this configuration example is directly copyable and lacks equivalent context. Users may therefore adopt the unsafe setting as a normal override. ### Attack Path 1. A user copies the documented command to connect to `myserver`. 2. An attacker gains a position on the network path or manipulates DNS resolution for the server. 3. The attacker presents an attacker-controlled SSH host key. 4. Because strict host-key checking is disabled, the SSH client may proceed without requiring trusted host authentication. 5. The user interacts with the attacker's SSH endpoint under the belief that it is the intended server. 6. Commands, uploaded files, and passwords entered during the session may be disclosed to the attacker. ### Impact Assessment This does not directly grant local administrative privileges or disclose the user's private SSH key. However, a successful server-impersonation attack can expose: - Passwords entered during the fraudulent session - Commands and sensitive command output - Files uploaded to the impersonated server - Opera ...[truncated 285 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Remove the unsafe example or replace it with a secure default: ```bash ssh -o StrictHostKeyChecking=accept-new myserver ``` Add explicit guidance that: - `accept-new` accepts previously unseen hosts but rejects changed keys. - `yes` should be used when the host key has already been securely provisioned. - `no` should not be presented as a routine connection or troubleshooting option. - Unexpected host-key changes must be investigated and verified through a trusted, independent channel. If the unsafe mode must remain for exceptional diagnostic scenarios, place a prominent warning immediately before the command and state that it must only be used in an isolated, controlled environment where server identity is verified by another mechanism. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:377
• Finding: Verified SSH Host Key Is Discarded and Re-Scanned Before Trust<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 377–382 **Vulnerability Type**: Time-of-check/time-of-use flaw in SSH host-key provisioning **Risk Level**: Medium ### Vulnerable Code ```bash # Verify and store a known-good host key (safe pre-population workflow) ssh-keyscan -t ed25519 hostname # (⚠️ Run ssh-keyscan independently first, compare the output against a trusted key # obtained via another channel (e.g., admin console, PGP-signed key page). Only then append: ssh-keyscan -t ed25519 hostname >> ~/.ssh/known_hosts # If the scanned key doesn't match the trusted key, DO NOT append it.) ``` ### Technical Analysis The workflow tells the user to inspect and verify the output of the first `ssh-keyscan` command, but it does not preserve that verified output. It then performs a second network request and appends the result of that separate scan directly to `known_hosts`. The second result is not necessarily identical to the first result. This creates a time-of-check/time-of-use condition: the data checked by the user is not the same data subsequently trusted by SSH. `ssh-keyscan` does not authenticate the key it retrieves. Its output is safe to trust only after the exact retrieved key has been verified through an independent trusted channel. ### Attack Path 1. The user runs the first `ssh-keyscan` command. 2. The user verifies that first result against a trusted fingerprint. 3. Before the second scan, an attacker manipulates DNS, routing, or the network path. 4. The second `ssh-keyscan` receives the attacker's host key. 5. The unverified second result is appended to `~/.ssh/known_hosts`. 6. The attacker later intercepts the SSH connection and presents the trusted attacker-controlled key. 7. SSH accepts the fraudulent host because its key was added to `known_hosts`. ### Impact Assessment A successful attack can establish persistent trust in an attacker-controlled host key for the specified hostname. This may enable subsequent ser ...[truncated 324 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Capture the key once, verify that exact content, and append the same verified bytes. For example: ```bash tmpfile="$(mktemp)" chmod 600 "$tmpfile" ssh-keyscan -t ed25519 hostname > "$tmpfile" # Display the exact candidate fingerprint. ssh-keygen -lf "$tmpfile" # Compare it with a fingerprint obtained through a trusted independent channel. # Append only after the exact fingerprint has been verified. cat "$tmpfile" >> ~/.ssh/known_hosts rm -f "$tmpfile" ``` Additional hardening should include: - Abort if `ssh-keyscan` fails or returns an unexpected number or type of keys. - Verify the exact ED25519 fingerprint through an administrator console, signed inventory, or another authenticated channel. - Avoid performing another network scan after verification. - Back up or review the existing `known_hosts` entry before replacing it. - Use a restrictive `umask`, such as `umask 077`, when creating temporary key material. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:159
• Finding: Misleading Encryption Guidance for SSH SOCKS and Port Forwarding<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 159–162 **Vulnerability Type**: Incorrect transport-encryption security guidance **Risk Level**: Medium ### Vulnerable Code ```bash # (⚠️ SOCKS5 traffic is NOT encrypted by default. Browsers configured to use a SOCKS proxy # may send credentials and data in cleartext. For encrypted proxy traffic, use SSH -L or -R # port forwarding instead of SOCKS, or use a TLS-based proxy like mitmproxy.) ``` ### Technical Analysis When dynamic forwarding is created with `ssh -D`, traffic between the local SSH client and the SSH server is carried inside the encrypted SSH connection. The connection from the SSH server to the final destination uses the application's own protocol and may be plaintext. The same endpoint limitation applies to `ssh -L` and `ssh -R`: these modes encrypt the SSH segment but do not automatically provide end-to-end application encryption beyond the SSH endpoint. Recommending `-L` or `-R` as an encrypted replacement for `-D` therefore creates a false security distinction. The reference to a TLS-capable proxy also does not eliminate the need to establish what segment is encrypted and whether the destination certificate is securely validated. ### Attack Path 1. A user reads that `-L` or `-R` provides encrypted proxy traffic compared with `-D`. 2. The user forwards an HTTP or another plaintext application protocol using `-L` or `-R`. 3. SSH encrypts traffic only up to the SSH endpoint. 4. The forwarded connection leaves the SSH endpoint using the plaintext application protocol. 5. An attacker monitoring the network between the SSH server and destination captures credentials or sensitive application data. ### Impact Assessment The issue does not grant additional system privileges by itself. Its impact is confidentiality and integrity loss for application traffic that users incorrectly assume is protected end to end. Potentially affected data includes: - HTTP authentication c ...[truncated 377 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Replace the warning with technically accurate guidance, such as: ```bash # SSH dynamic forwarding encrypts traffic between this client and the SSH server. # Traffic from the SSH server to the final destination is protected only if the # application protocol uses end-to-end encryption, such as HTTPS with valid # certificate verification. The same limitation applies to SSH -L and -R forwarding. ``` Also advise users to: - Use HTTPS, TLS, SSH, or another authenticated end-to-end encrypted application protocol. - Validate destination certificates and hostnames. - Avoid sending credentials over HTTP or other plaintext protocols. - Treat the SSH server as a trusted traffic endpoint. - Configure remote DNS resolution where appropriate to reduce local DNS leakage, while clarifying that this does not create end-to-end payload encryption. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (41)

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh -v user@hostname

# Connect with specific key
ssh -i ~/.ssh/id_rsa user@hostname

# Connect and run command
ssh user@hostname 'ls -la'

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname

# Manual key copy
cat ~/.ssh/id_rsa.pub | ssh user@hostname 'cat >> ~/.ssh/authorized_keys'

# Check key fingerprint
ssh-keygen -lf ~/.ssh/id_rsa.pub

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname

# Manual key copy
cat ~/.ssh/id_rsa.pub | ssh user@hostname 'cat >> ~/.ssh/authorized_keys'

# Check key fingerprint
ssh-keygen -lf ~/.ssh/id_rsa.pub

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Review the output, then execute the real command

# Sync with delete (mirror) — only after dry-run confirms expected changes
rsync -avz --delete /local/dir/ user@hostname:/remote/dir/
# (⚠️ DELETION WARNING: This removes files from the destination that aren't in the source.
#  Double-check --dry-run output before running. Consider using --ignore-errors for large transfers.)

• Confidence: 80% confidence
• Finding: The skill provides a live `rsync --delete` command that will remove destination files not present in the source. Although it includes warnings and recommends a prior dry run, users may still copy-paste it and cause unintended destructive data loss, especially in automation or when source/destination paths are mistaken.

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

**Why:** Issue #6 — No warning about plaintext key storage risk.

• Confidence: 80% confidence
• Finding: Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

rsync -avz --progress /local/dir/ user@hostname:/remote/dir/

# Sync with delete (mirror)
rsync -avz --delete /local/dir/ user@hostname:/remote/dir/

# Exclude patterns
rsync -avz --exclude '*.log' --exclude 'node_modules/' \

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

rsync -avz --progress /local/dir/ user@hostname:/remote/dir/

# Sync with delete (mirror)
rsync -avz --delete /local/dir/ user@hostname:/remote/dir/

# Exclude patterns
rsync -avz --exclude '*.log' --exclude 'node_modules/' \

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

rsync -avz --progress /local/dir/ user@hostname:/remote/dir/

# Sync with delete (mirror)
rsync -avz --delete /local/dir/ user@hostname:/remote/dir/

# Exclude patterns
rsync -avz --exclude '*.log' --exclude 'node_modules/' \

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

# Review the output, then execute the real command

# Sync with delete (mirror) — only after dry-run confirms expected changes
rsync -avz --delete /local/dir/ user@hostname:/remote/dir/
# (⚠️ DELETION WARNING: This removes files from the destination that aren't in the source.
#  Double-check --dry-run output before running. Consider using --ignore-errors for large transfers.)

• Confidence: 80% confidence
• Finding: Even with warnings, the document still includes a live `rsync --delete` command that readers may copy-paste into production. Because `--delete` irreversibly removes destination files missing from the source, path mistakes, trailing-slash confusion, or reversed source/destination can cause destructive data loss.

Credential Access

High

• Category: Privilege Escalation

Content

ssh-keyscan -t ed25519 hostname
# (⚠️ Run ssh-keyscan independently first, compare the output against a trusted key
#  obtained via another channel (e.g., admin console, PGP-signed key page). Only then append:
ssh-keyscan -t ed25519 hostname >> ~/.ssh/known_hosts
#  If the scanned key doesn't match the trusted key, DO NOT append it.)

# Use specific cipher

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

ssh-keyscan -t ed25519 hostname
# (⚠️ Run ssh-keyscan independently first, compare the output against a trusted key
#  obtained via another channel (e.g., admin console, PGP-signed key page). Only then append:
ssh-keyscan -t ed25519 hostname >> ~/.ssh/known_hosts
#  If the scanned key doesn't match the trusted key, DO NOT append it.)

# Use specific cipher

• Confidence: 90% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

1. **SOCKS Proxy (Dynamic Port Forwarding)** — No security note about SOCKS5 traffic being unencrypted by default. Users connecting a browser through SOCKS may assume traffic is encrypted.

2. **Remote Port Forwarding (`-R`)** — No warning that `-R` exposes local services to the remote server. This is a significant risk when connecting to untrusted bastion hosts.

3. **SCP Deprecation** — The plan doesn't mention that `scp` is deprecated in modern OpenSSH and `sftp` should be preferred for file transfers.

• Confidence: 80% confidence
• Finding: Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# Disable root login
PermitRootLogin no
# (⚠️ System administrators should use sudo through a bastion host instead of direct root login.)

# Change default port
Port 2222

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Static analysis

No suspicious patterns detected.