Skip to content

New Skill: added the tunneling skill with tinyfi.sh #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
simantak-dabhade merged 1 commit into from
Feb 5, 2026
Merged

New Skill: added the tunneling skill with tinyfi.sh #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions skills/tunneling/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
name: tunneling
description: Create free SSH tunnels to expose local ports to the internet using tinyfi.sh. Use when you need to share a locally running app, test webhooks, demo a prototype, or get a public HTTPS URL for any local service — no signup or authentication required.
---

# TinyFish Tunneling Service (tinyfi.sh)

Creates instant public HTTPS URLs for locally running apps via SSH tunneling. Free, no account, no installation beyond SSH.

## Pre-flight Check (REQUIRED)

Verify SSH is available (it almost always is):

```bash
which ssh && echo "SSH available" || echo "SSH not found — install OpenSSH first"
```

## Quick Start

Expose a local port to the internet:

```bash
ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:<PORT> tinyfi.sh
```
Comment on lines +22 to +24
Copy link

@coderabbitai coderabbitai bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

tinyfi.sh official documentation SSH command StrictHostKeyChecking

💡 Result:

tinyfi.sh’s official docs show connecting with a plain reverse-tunnel command and do not mention StrictHostKeyChecking:

  • ssh -R 80:localhost:3000 tinyfi.sh (example from the tinyfi.sh homepage docs) [1]

If you specifically need to control host-key checking, that’s an OpenSSH client option, not something documented as required by tinyfi.sh. For example (use with care):

  • ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh
  • ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 80:localhost:3000 tinyfi.sh

Source: tinyfi.sh homepage documentation [1]

References:
[1] tinyfi.sh (homepage) https://tinyfi.sh/

Align command with official tinyfi.sh documentation or add clarification.

The SKILL.md command includes -o StrictHostKeyChecking=accept-new, but the official tinyfi.sh documentation shows the simpler command without this option: ssh -R 80:localhost:3000 tinyfi.sh. The StrictHostKeyChecking parameter is a client-side SSH option, not part of tinyfi.sh's official guidance. Either use the documented command or add a note explaining why this modification is included and its security implications.

🤖 Prompt for AI Agents 
In `@skills/tunneling/SKILL.md` around lines 22 - 24, The SSH example in SKILL.md
currently uses the client-side option "-o StrictHostKeyChecking=accept-new" —
either remove that option and replace the snippet with the official documented
form "ssh -R 80:localhost:<PORT> tinyfi.sh" to match tinyfi.sh docs, or keep the
option but add one concise sentence immediately after the command explaining why
it's included and its security implications (that it disables strict host key
prompts and may accept unknown host keys), referencing the exact snippet and the
"-o StrictHostKeyChecking=accept-new" flag so reviewers can find and update it.


Replace `<PORT>` with the port your app is running on. The command will print a public `https://<random>.tinyfi.sh` URL.

## Custom Subdomain

Request a specific subdomain instead of a random one:

```bash
ssh -o StrictHostKeyChecking=accept-new -R myname:80:localhost:<PORT> tinyfi.sh
```

This gives you `https://myname.tinyfi.sh`.

## Keep-Alive (Stable Connections)

For long-running tunnels, add a keep-alive interval to prevent disconnection:

```bash
ssh -o StrictHostKeyChecking=accept-new -o ServerAliveInterval=60 -R 80:localhost:<PORT> tinyfi.sh
```

## Usage Guidelines

When starting a tunnel for the user:

1. **Ask which port** to expose if not already specified
2. **Run the SSH command** in the background so the agent can continue working
3. **Report the public URL** back to the user once the tunnel is established
4. The tunnel stays open as long as the SSH connection is alive

Comment on lines +46 to +54
Copy link

@coderabbitai coderabbitai bot Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Add practical examples for background execution.

The guidelines instruct to "run the SSH command in the background" (line 51) and "report the public URL" (line 52), but don't provide any examples of how to accomplish this. Users need concrete guidance on:

  • How to background the SSH process (e.g., using &, spawning in a subprocess, etc.)
  • How to capture and parse the tunnel URL from SSH output
  • How to monitor if the tunnel is still alive

This is essential for implementing these guidelines correctly.

📝 Suggested enhancement with practical examples

Consider adding a section like:

## Running Tunnels in the Background

To run a tunnel without blocking:

**Option 1: Background process**
```bash
ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh > tunnel_output.txt 2>&1 &
TUNNEL_PID=$!

Option 2: Using nohup for persistent tunnels

nohup ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh > tunnel_output.txt 2>&1 &

Parse the URL from output:

sleep 2  # Wait for connection
grep -oP 'https://[^/]+\.tinyfi\.sh' tunnel_output.txt

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

In @skills/tunneling/SKILL.md around lines 46 - 54, Add a concrete "Running
Tunnels in the Background" subsection to the skill docs (adjacent to the "Usage
Guidelines" section) that gives practical examples for backgrounding SSH (e.g.,
shell backgrounding, nohup, or spawning a subprocess), shows how to
capture/parse the public tunnel URL from SSH output (e.g., redirecting
stdout/stderr to a file or reading subprocess stdout and using a regex to
extract the URL), and explains simple monitoring/restart strategies (e.g.,
checking the PID/alive status or tailing output and respawning on failure).
Reference the phrases "run the SSH command in the background" and "report the
public URL" so readers can find the updated guidance easily.


</details>

<!-- fingerprinting:phantom:triton:puma -->

<!-- This is an auto-generated comment by CodeRabbit -->

## Common Ports

| Framework / Tool | Default Port |
|----------------------|-------------|
| Next.js / React / Express | 3000 |
| Vite | 5173 |
| Django | 8000 |
| Flask | 5000 |
| Go (net/http) | 8080 |
| Ruby on Rails | 3000 |
| PHP (built-in) | 8000 |

## Rate Limits

- 5 SSH connections per minute per IP
- 100 HTTP requests per minute per IP
- 50 concurrent connections max
- 48-hour idle timeout