Got a server running on port 3000? Run
ssh srv.us -R 1:localhost:3000 and it’ll respond with its public HTTPS URL(s), available until you close
ssh with Ctrl-c or Ctrl-d, or get disconnected (see Staying up).
It fails with
Permission denied (publickey).? You need an SSH key; use
ssh-keygen -t ed25519 (defaults work). Another problem? Contact support.
If you forget the syntax,
ssh srv.us prints an example.
Set up 2 tunnels, the first to
3000 and the second to
$ ssh srv.us -R 1:localhost:3000 -R 2:192.168.0.1:80 1: https://qp556ma755ktlag5b2xyt334ae.srv.us/, https://pcarrier.gh.srv.us/ 2: https://z2tdoto6u3mddntra45qkm45ci.srv.us/, https://pcarrier--2.gh.srv.us/
Test the first tunnel with a single-request server:
$ printf 'HTTP/1.1 200 OK\r\n\r\nHello through srv.us!\n' | nc -l 3000 > /dev/null & $ curl https://qp556ma755ktlag5b2xyt334ae.srv.us/ Hello through srv.us!
If either GitHub or GitLab authorizes your SSH key for your login, we also expose your tunnels over correspondingly named URLs.
For example, for login
(The discrepancy is due to insufficient constraints on GitLab usernames.
We need to prevent collisions between users
jdoe and eg
whereas GitHub does not allow repeating
- in usernames.)
Note that this feature is optional and might not work out of the box:
ssh firstname.lastname@example.org …;
ssh email@example.com ….
ssh eventually terminates when the connection is lost or the service restarted.
until ssh srv.us -R 1:localhost:3000; do echo Restarting…; done.
When there are multiple tunnels for a URL, client connections are spread between them randomly. We do not perform any health checks.
We do not record any of your traffic.
However, we log IPs & ports, SSH usernames & keys, connections, tunnels, and byte counts for up to 1 day.
Those logs never leave the server, and are only ever used for operational purposes and to troubleshoot reported issues.
We reserve the right to access your endpoint in the handling of abuse reports.
The Go backend runs on as a systemd service on a single instance and uses certificates provisioned by Let’s Encrypt using a systemd timer with a corresponding service where
ExecStart=/snap/bin/certbot renew --agree-tos --manual --preferred-challenges=dns --post-hook /usr/local/bin/certbot-renewed --manual-auth-hook /usr/local/bin/certbot-auth (
certbot-renewed restarts the backend and
certbot-auth integrates with CloudFlare’s DNS API). I have plans to scale when it becomes necessary.
Non-HTTP protocols work too, as we only rely on the protocol to report errors.
The bandwidth used for your traffic is consumed twice. If sponsorships don’t cover operating costs and they increase significantly, heavy usage may require financial contribution to avoid throttling.