GitHub Passwordless Setup

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:41 PM UTC
• Version: 1.0.0

Overview

The skill matches its GitHub authentication purpose, but it asks users to run mutable remote shell code and create broad, durable GitHub credentials with account-changing verification steps.

Install only after reviewing the scripts locally. Avoid the curl-to-bash command, prefer a passphrase-protected SSH key, use a fine-grained short-lived token with only the permissions you need, and do not run the create/delete repository verification unless you explicitly want account-state changes.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: README.md:21
• Finding: Mutable Remote Script Is Downloaded and Executed Without Verification<![CDATA[ ## Vulnerability Details **File Location**: `README.md:21`, `README.zh-CN.md:21`, `SKILL.md:34` **Vulnerability Type**: Unverified remote code retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash curl -fsSL https://raw.githubusercontent.com/happydog-intj/github-passwordless-setup/master/setup.sh | bash ``` ### Technical Analysis The documented installation command retrieves a shell script from the mutable `master` branch of a personal GitHub repository and sends the response directly to Bash. It does not pin the content to an immutable commit, verify a cryptographic signature or checksum, or provide the user an opportunity to inspect the downloaded script before execution. Consequently, the effective code executed by users can differ from the locally audited `setup.sh`. The bundled script currently appears consistent with the declared SSH and GitHub CLI setup functionality, but that does not establish the integrity of future responses from the remote URL. The behavior exceeds the minimum privilege necessary for installation because executing an unverified network response is not required. The project can instead distribute and invoke its bundled script or use a verified release artifact. ### Attack Path 1. An attacker compromises the referenced GitHub account, repository, branch, or a maintainer credential, or otherwise obtains the ability to alter `master/setup.sh`. 2. The attacker replaces the remote script with arbitrary shell commands. 3. A user follows the documented quick-start command. 4. `curl` retrieves the changed content without integrity verification. 5. Bash immediately executes the response with the invoking user's privileges. 6. The payload can access the user's files and configuration and can observe or interfere with the SSH and GitHub authentication setup session. ### Impact Assessment Successful exploitation provides arbitrary code execution under the invoking user's account. This can expose or modi ...[truncated 582 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove every `curl | bash` installation instruction. 2. Prefer executing the reviewed script included with the downloaded project: ```bash git clone https://github.com/happydog-intj/github-passwordless-setup.git cd github-passwordless-setup less setup.sh chmod +x setup.sh ./setup.sh ``` 3. If direct downloads must remain supported: - Pin the URL to an immutable commit hash or signed release. - Publish a SHA-256 checksum through a separately protected channel. - Download to a local file. - Verify the checksum or signature. - Let the user inspect the file before execution. ```bash curl -fLO "https://example.invalid/releases/setup.sh" echo "EXPECTED_SHA256 setup.sh" | sha256sum --check - less setup.sh bash setup.sh ``` 4. Apply the same corrected instructions to `README.md`, `README.zh-CN.md`, and `SKILL.md`. 5. Protect release publication with multi-factor authentication, branch protection, signed commits or tags, and restricted maintainer access. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: setup.sh:50
• Finding: Authentication Setup Encourages Broad, Long-Lived Credentials and an Unencrypted SSH Key<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:50`, `setup.sh:145-158`, `SKILL.md:103-109`, `SKILL.md:239` **Vulnerability Type**: Insecure credential configuration and violation of least privilege **Risk Level**: High ### Vulnerable Code From `setup.sh`: ```bash ssh-keygen -t ed25519 -C "$USER_EMAIL" -f ~/.ssh/id_ed25519 -N "" ``` ```bash echo "To create a token:" echo " 1. Visit: https://github.com/settings/tokens/new" echo " 2. Note: 'OpenClaw CLI Token' (or any description)" echo " 3. Expiration: 'No expiration' (or 90 days)" echo " 4. Scopes: ✅ repo (select all sub-scopes)" echo " 5. Click 'Generate token' and copy it" echo "" echo "Token format: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" echo "" # Logout any existing sessions gh auth logout -h github.com 2>/dev/null || true echo "Please paste your GitHub Personal Access Token:" gh auth login --with-token ``` The detailed instructions in `SKILL.md` additionally recommend optional classic-token scopes including: ```text repo workflow delete_repo admin:org ``` They also permit a token with no expiration. ### Technical Analysis The script forces an empty SSH private-key passphrase through `-N ""`. This provides passwordless operation but removes an important defense if the private key file is copied from the host. The documentation calls passphrases recommended elsewhere, but the automated setup does not offer that secure default. The token guidance recommends all classic `repo` sub-scopes and permits no expiration. The detailed Skill documentation also presents `workflow`, `delete_repo`, and `admin:org` scopes. These capabilities are not inherently required for ordinary SSH-based Git push, pull, and clone operations. Repository deletion, workflow modification, and organization administration should only be granted for explicitly selected workflows. A non-expiring, broad classic PAT increases both the useful lifetime and authorization scope of a stolen credential. This confli ...[truncated 1600 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Use a fine-grained Personal Access Token instead of a broad classic PAT where possible. 2. Default to the shortest practical expiration and require periodic rotation. 3. Request only permissions required for the user's selected operations. Do not recommend `workflow`, `delete_repo`, or `admin:org` by default. 4. Explain that SSH Git operations do not require a PAT; a token is only necessary for selected GitHub CLI or API operations. 5. Divide setup into explicit capability profiles, such as: - Git over SSH only. - Read-only GitHub CLI access. - Repository management. - Optional destructive or organization administration. 6. Let `ssh-keygen` securely prompt for a passphrase rather than forcing `-N ""`: ```bash ssh-keygen -t ed25519 -C "$USER_EMAIL" -f "$HOME/.ssh/id_ed25519" ``` 7. If unattended key generation is genuinely required, clearly warn that the resulting key is unencrypted, require explicit opt-in, and recommend using a constrained dedicated key. 8. Avoid displaying realistic token placeholders in shell commands where they could encourage tokens to be placed in shell history. Continue using `gh auth login --with-token` through standard input or the GitHub CLI's supported secure interactive flow. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: setup.sh:193
• Finding: Verification Performs Unnecessary Public Repository Creation and Destructive Deletion<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:193-200`, `verify.sh:73-84` **Vulnerability Type**: State-changing verification with excessive permissions **Risk Level**: Medium ### Vulnerable Code From `setup.sh`: ```bash TEST_REPO="test-auth-verify-$(date +%s | tail -c 6)" if gh repo create "$TEST_REPO" --public --description "Automated test" &> /dev/null; then echo -e "${GREEN}✅ Repository creation: Working${NC}" # Delete test repo if gh repo delete "$(gh api user --jq '.login')/$TEST_REPO" --yes &> /dev/null; then echo -e "${GREEN}✅ Repository deletion: Working${NC}" fi fi ``` From `verify.sh`: ```bash TEST_REPO="test-verify-$(date +%s | tail -c 6)" if gh repo create "$TEST_REPO" --public --description "Test" &> /dev/null; then echo -e "${GREEN} ✅ Create repository: Working${NC}" if gh repo delete "$(gh api user --jq '.login')/$TEST_REPO" --yes &> /dev/null; then echo -e "${GREEN} ✅ Delete repository: Working${NC}" else echo -e "${YELLOW} ⚠️ Delete repository: Failed${NC}" fi else echo -e "${RED} ❌ Create repository: Failed${NC}" ERRORS=$((ERRORS + 1)) fi ``` ### Technical Analysis Both setup and verification perform externally visible, state-changing operations against the user's GitHub account. They create a public repository and then attempt to delete it without a separate confirmation at the point of mutation. Repository creation and deletion are not necessary to verify SSH authentication, GitHub CLI authentication, or basic API connectivity. Read-only operations such as `ssh -T`, `gh auth status`, and `gh api user` already establish those conditions. The test also creates pressure to grant repository creation and deletion privileges solely so verification can pass. If deletion fails because of missing permission, network failure, interruption, rate limiting, or API errors, the public test repository remains in the user's account. ### Attack Pat ...[truncated 1327 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove repository creation and deletion from default setup and verification. 2. Use read-only checks instead: ```bash ssh -T [e-mail] gh auth status gh api user --jq '.login' gh config get git_protocol ``` 3. If an end-to-end mutation test is retained: - Make it an explicit opt-in operation. - Explain the exact account changes and permissions required. - Ask for confirmation immediately before repository creation. - Prefer a private repository when the user's plan and permissions support it. - Record the exact owner and repository name without deriving a deletion target from repository listings. - Install robust cleanup handling with `trap`. - Clearly report cleanup failure and provide the exact manual deletion command. 4. Do not treat inability to delete repositories as a failure of ordinary SSH or GitHub CLI authentication. 5. Remove `delete_repo` from default token recommendations and request it only for an explicitly approved deletion test. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (78)

Credential Access

High

• Category: Privilege Escalation

Content

Configures **complete passwordless authentication** for GitHub using:
1. **SSH Keys** - Zero-password Git operations (push/pull/clone)
2. **Personal Access Token** - Zero-password repository management

**One-time setup, lifetime convenience!**

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

Credential Access

High

• Category: Privilege Escalation

Content

Configures **complete passwordless authentication** for GitHub using:
1. **SSH Keys** - Zero-password Git operations (push/pull/clone)
2. **Personal Access Token** - Zero-password repository management

**One-time setup, lifetime convenience!**

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

Credential Access

High

• Category: Privilege Escalation

Content

Configures **complete passwordless authentication** for GitHub using:
1. **SSH Keys** - Zero-password Git operations (push/pull/clone)
2. **Personal Access Token** - Zero-password repository management

**One-time setup, lifetime convenience!**

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

Credential Access

High

• Category: Privilege Escalation

Content

Configures **complete passwordless authentication** for GitHub using:
1. **SSH Keys** - Zero-password Git operations (push/pull/clone)
2. **Personal Access Token** - Zero-password repository management

**One-time setup, lifetime convenience!**

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

Chaining Abuse

High

• Category: Tool Misuse

Content

## ⚡ Quick Start

```bash
curl -fsSL https://raw.githubusercontent.com/happydog-intj/github-passwordless-setup/master/setup.sh | bash
```

## ✨ Before vs After

• Confidence: 98% confidence
• Finding: The use of '| bash' chains network retrieval directly into shell execution, eliminating the user's opportunity to inspect the contents before running them. This pattern is especially risky in setup skills because it normalizes blind execution and can be abused for command chaining, persistence, or credential theft if the remote script is ever altered maliciously.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The README instructs users to fetch and immediately execute a remote shell script via `curl ... | bash`, which prevents review of the script before execution and gives the remote content full code-execution capability on the user's machine. In the context of a credential-setup skill, this is especially dangerous because the script likely handles SSH keys and GitHub authentication state, so a compromised script or repository could exfiltrate tokens, private keys, or alter git/gh configuration.

Chaining Abuse

High

• Category: Tool Misuse

Content

## ⚡ 快速开始

```bash
curl -fsSL https://raw.githubusercontent.com/happydog-intj/github-passwordless-setup/master/setup.sh | bash
```

## ✨ 配置前后对比

• Confidence: 98% confidence
• Finding: The `| bash` pipeline removes the user's opportunity to inspect downloaded content and immediately turns a network fetch into arbitrary shell execution. In a setup tool that manages passwordless GitHub access, this materially increases risk because a malicious script could silently harvest credentials or implant persistence in shell and git configuration.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The skill’s stated purpose is authentication setup, but it also performs active verification with side effects, including creating and deleting a repository on the user’s GitHub account. That mismatch can cause unexpected account actions and broadens the trust required from the user beyond simple local configuration.

Credential Access

High

• Category: Privilege Escalation

Content

---
name: github-passwordless-setup
description: Complete GitHub passwordless authentication setup using SSH keys and Personal Access Tokens. Never type passwords or re-authenticate for Git operations and GitHub API calls.
---

# GitHub Passwordless Setup

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

Credential Access

High

• Category: Privilege Escalation

Content

---
name: github-passwordless-setup
description: Complete GitHub passwordless authentication setup using SSH keys and Personal Access Tokens. Never type passwords or re-authenticate for Git operations and GitHub API calls.
---

# GitHub Passwordless Setup

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

Credential Access

High

• Category: Privilege Escalation

Content

---
name: github-passwordless-setup
description: Complete GitHub passwordless authentication setup using SSH keys and Personal Access Tokens. Never type passwords or re-authenticate for Git operations and GitHub API calls.
---

# GitHub Passwordless Setup

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

Chaining Abuse

High

• Category: Tool Misuse

Content

One-line automated setup:

```bash
curl -fsSL https://raw.githubusercontent.com/happydog-intj/github-passwordless-setup/master/setup.sh | bash
```

Or follow the manual steps below.

• Confidence: 99% confidence
• Finding: `curl ... | bash` is a classic dangerous chaining pattern because it turns remote content into immediate code execution without inspection, provenance validation, or pinning. In this skill context, the command is especially risky because it is presented as the primary quick-start path.

Chaining Abuse

High

• Category: Tool Misuse

Content

**Linux (Debian/Ubuntu):**
```bash
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Credential Access

High

• Category: Privilege Escalation

Content

**Linux (Debian/Ubuntu):**
```bash
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update

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

Credential Access

High

• Category: Privilege Escalation

Content

**Linux (Debian/Ubuntu):**
```bash
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update

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

Credential Access

High

• Category: Privilege Escalation

Content

**Linux (Debian/Ubuntu):**
```bash
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update

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

Chaining Abuse

High

• Category: Tool Misuse

Content

**Linux (Debian/Ubuntu):**
```bash
type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update

• Confidence: 90% confidence
• Finding: Piping remotely fetched content directly into a privileged writer (`curl ... | sudo dd`) reduces user visibility into what is being installed and amplifies the impact of a compromised upstream or network path. While common in repository setup snippets, it is still an unsafe pattern because untrusted bytes are immediately committed under elevated privileges.

Chaining Abuse

High

• Category: Tool Misuse

Content

type -p curl >/dev/null || (sudo apt update && sudo apt install curl -y)
curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh -y
```

• Confidence: 86% confidence
• Finding: Piping repository configuration text into `sudo tee` writes privileged configuration non-interactively and encourages users not to inspect the exact file contents before installation. In combination with other setup steps, this increases the chance of silently adding an unintended package source.

Credential Access

High

• Category: Privilege Escalation

Content

# If empty or error, add your key
ssh-add ~/.ssh/id_ed25519

# macOS: Add to Keychain permanently
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
```

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

Credential Access

High

• Category: Privilege Escalation

Content

# If empty or error, add your key
ssh-add ~/.ssh/id_ed25519

# macOS: Add to Keychain permanently
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
```

• Confidence: 70% 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-add ~/.ssh/id_ed25519

# macOS: Add to Keychain permanently
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
```

**Problem: "Host key verification failed"**

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

Credential Access

High

• Category: Privilege Escalation

Content

export GH_TOKEN="ghp_xxxxx"  # Auto-auth for gh commands

# Git
export GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519"  # Force specific key
```

Add to your shell profile (`~/.bashrc`, `~/.zshrc`):

• Confidence: 94% confidence
• Finding: The `GH_TOKEN` export example promotes storing a sensitive PAT in an environment variable, which can be exposed to subprocesses, debugging tools, logs, and misconfigured shell profiles. In contrast, the `GIT_SSH_COMMAND` portion is not the issue; the danger is teaching persistent token exposure patterns.

Credential Access

High

• Category: Privilege Escalation

Content

# Logout any existing sessions
gh auth logout -h github.com 2>/dev/null || true

echo "Please paste your GitHub Personal Access Token:"
gh auth login --with-token

# Set git protocol to SSH

• Confidence: 81% confidence
• Finding: Prompting the user to paste a GitHub Personal Access Token into the terminal is credential handling that increases exposure risk, especially when the script recommends broad `repo` access and long-lived tokens. In this skill context, collecting privileged credentials is expected but still more dangerous because the token can enable account-wide API actions beyond simple Git transport.

Credential Access

High

• Category: Privilege Escalation

Content

# Check 1: SSH Key
echo -e "${YELLOW}1️⃣ Checking SSH Key...${NC}"
if [ -f ~/.ssh/id_ed25519.pub ] || [ -f ~/.ssh/id_rsa.pub ]; then
    echo -e "${GREEN}   ✅ SSH key exists${NC}"
    
    # Test connection

• 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

# Check 1: SSH Key
echo -e "${YELLOW}1️⃣ Checking SSH Key...${NC}"
if [ -f ~/.ssh/id_ed25519.pub ] || [ -f ~/.ssh/id_rsa.pub ]; then
    echo -e "${GREEN}   ✅ SSH key exists${NC}"
    
    # Test connection

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

Static analysis

No suspicious patterns detected.