Menu
Expose this machine over SSH via bore (public TCP tunnel).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use for any Microsoft account, personal or work (Outlook.com, Hotmail, Live, Microsoft 365); preferred over email-client for Microsoft accounts. Graph-based mail (read/send/reply/forward, drafts, flag/categorize, move/archive, folders, attachments, block senders), calendar and meetings, Microsoft Teams (chats, channels, presence), and new-mail/Teams notifications. Requires daemon.
Browse, navigate, click, fill forms, screenshot, or scrape web pages with a stealth (Camoufox) browser.
Design judgment and UI copy for building Vesta dashboard widgets that feel considered rather than templated, within the fixed design system.
Use before building or modifying the user's dashboard: widgets, pages, layouts, custom UI. Understand what the user wants, design it, write a spec, then dispatch the dashboard-builder to build it.
Use when someone who doesn't have their own vesta asks what vesta is, how to get one, or hints they want in. Vesta is invite-only: you gatekeep and build desire through scarcity, draw out what they want, then sell vesta as indispensable to their goals and set them up end-to-end in chat. Not for the owner, who already has one.
Talk to vestad, the host daemon that runs this container. Register a background service to get a port, build public URLs, update vestad to the latest release, check its version, and read gateway logs. Use when a skill needs an inbound port or a shareable link, when the user asks to update Vesta, or when debugging gateway/container issues.
| name | ssh |
| description | Expose this machine over SSH via bore (public TCP tunnel). |
Exposes this machine over the internet via bore, a free TCP relay. Runs its own sshd on a dynamically allocated port inside the container (independent of the host SSH server, no port conflicts between containers) so all auth is fully controlled. No account required. The connecting machine only needs a standard SSH client.
Ask the user to run this on the machine that will be connecting:
cat ~/.ssh/id_ed25519.pub
# or if using RSA:
cat ~/.ssh/id_rsa.pub
If they don't have a key yet:
ssh-keygen -t ed25519 # press Enter for all prompts
cat ~/.ssh/id_ed25519.pub
They should paste the full output (one line starting with ssh-ed25519 or ssh-rsa).
~/agent/skills/ssh/scripts/start.sh "ssh-ed25519 AAAA... user@laptop"
Running start.sh again with a different key adds it without removing existing ones (idempotent).
The script prints the exact command. It will look like:
ssh -o StrictHostKeyChecking=accept-new root@bore.pub -p 12345
The host key is the container's sshd key and stays stable across bore reconnects.
If the connecting machine has multiple SSH keys and the wrong one is picked:
ssh -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=accept-new root@bore.pub -p 12345
~/agent/skills/ssh/scripts/status.sh
Shows whether sshd and bore are running, the current connection command, and which keys are authorized.
~/agent/skills/ssh/scripts/stop.sh
Stops both the bore tunnel and the sshd process. Authorized keys remain in ~/.ssh/authorized_keys for the next session.
start.sh is run. Share the new port with the connecting machine.screen session named bore-ssh. If bore dies unexpectedly: screen -r bore-ssh to inspect, then re-run start.sh.scp -P 12345 -o StrictHostKeyChecking=accept-new file root@bore.pub:~/destination/rsync -e "ssh -p 12345 -o StrictHostKeyChecking=accept-new" file root@bore.pub:~/destination/