Pi Web Secure Remote Access: SSH Tunneling, Reverse Proxy, and No Authentication Risk

This tutorial from Pi Web only deals with the specific task in the title. Pi Web only listens to 127.0.0.1 by default and does not have application layer authentication; it can call high-privilege Agent, so SSH local forwarding is preferred for remote access instead of directly binding to 0.0.0.0.

All the following operations are first placed in the test repository, test account or service that listens only on the loopback interface. The domain name, username, path and key in the command are placeholders and need to be replaced before execution.

First understand the non-authentication boundary of Pi Web

This section solves the problem of “first understanding the non-authentication boundary of Pi Web”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For Pi Web, the basis for judgment is: Pi Web only listens to 127.0.0.1 by default and does not have application layer authentication; it can call high-privilege Agent, so SSH local forwarding is preferred for remote access instead of directly binding to 0.0.0.0. Don’t accidentally open more permissions at this stage.

1

netstat -ano | Select-String '30141'

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Node.js 22.19 version check

Process in the following order:

1. Read the actual version and current configuration.
2. Change only one setting relevant to this section.
3. Run a read-only or revocable request.
4. Check logs, exit codes, and final files.
5. Revert the previous modification if it fails.

1

node --version

The completion criterion here is not that the interface appears, but that the “Node.js 22.19 version check” has repeatable results.

Keep loopback monitoring to start the service

1

npx @agegr/pi-web@latest --hostname 127.0.0.1 --port 30141 --no-open

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

Full path for SSH local port forwarding

Prepare a success sample and a failure sample around “Full path for SSH local port forwarding”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1

ssh -L 30141:127.0.0.1:30141 user@server

It is recommended to record the following four items:

• Pre-execution version or Git commit.
• Actual input, no secret value recorded.
• Observable output, status code or diff.
• Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Confirm from the client that the port is only open on this machine

This section solves the problem of “confirming from the client that the port is only open on this machine”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For Pi Web, the basis for judgment is: Pi Web only listens to 127.0.0.1 by default and does not have application layer authentication; it can call high-privilege Agent, so SSH local forwarding is preferred for remote access instead of directly binding to 0.0.0.0. Don’t accidentally open more permissions at this stage.

1

curl.exe http://127.0.0.1:30141

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

How to isolate session files in multi-user servers

Process in the following order:

1. Read the actual version and current configuration.
2. Change only one setting relevant to this section.
3. Run a read-only or revocable request.
4. Check logs, exit codes, and final files.
5. Revert the previous modification if it fails.

1

Get-ChildItem -Force $env:USERPROFILE\.pi -ErrorAction SilentlyContinue

The completion criterion here is not that the interface appears, but that “how does a multi-user server isolate session files” have repeatable results.

Why is it not recommended to use 0.0.0.0 directly?

1

pi-web --hostname 127.0.0.1 --port 30141 --no-open

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

What protections should be added when it is necessary to reverse generation?

Prepare a success sample and a failure sample around “what protections should be added when retrogeneration is necessary”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1

caddy validate --config Caddyfile

It is recommended to record the following four items:

• Pre-execution version or Git commit.
• Actual input, no secret value recorded.
• Observable output, status code or diff.
• Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

How to pass proxy environment variables to server requests

This section solves “How to pass proxy environment variables to server requests”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For Pi Web, the basis for judgment is: Pi Web only listens to 127.0.0.1 by default and does not have application layer authentication; it can call high-privilege Agent, so SSH local forwarding is preferred for remote access instead of directly binding to 0.0.0.0. Don’t accidentally open more permissions at this stage.

1
2
3

$env:HTTP_PROXY='http://127.0.0.1:7890'
$env:HTTPS_PROXY=$env:HTTP_PROXY
$env:NO_PROXY='localhost,127.0.0.1'

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Tunnel disconnection and page false online

Process in the following order:

1. Read the actual version and current configuration.
2. Change only one setting relevant to this section.
3. Run a read-only or revocable request.
4. Check logs, exit codes, and final files.
5. Revert the previous modification if it fails.

1

Test-NetConnection 127.0.0.1 -Port 30141

The completion criterion here is not that the interface appears, but that “tunnel disconnection and page false online” have repeatable results.

Close the service and clean up the remaining ports

1

Get-NetTCPConnection -LocalPort 30141 -ErrorAction SilentlyContinue

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

Remote access acceptance checklist

Prepare a success sample and a failure sample around the “Remote Access Acceptance Checklist”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1

curl.exe -I http://127.0.0.1:30141

It is recommended to record the following four items:

• Pre-execution version or Git commit.
• Actual input, no secret value recorded.
• Observable output, status code or diff.
• Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Restrict SSH forwarding accounts

This section addresses “Restricting SSH forwarding accounts”. First record the current state, then perform the minimum action, and finally confirm the result with independent evidence.

For Pi Web, the basis for judgment is: Pi Web only listens to 127.0.0.1 by default and does not have application layer authentication; it can call high-privilege Agent, so SSH local forwarding is preferred for remote access instead of directly binding to 0.0.0.0. Don’t accidentally open more permissions at this stage.

1

ssh -v -L 30141:127.0.0.1:30141 user@server

Preserve command output and timestamp after execution. If the output depends on temporary variables in the current terminal, open a new terminal and check again.

Backup boundaries for Pi session files

Process in the following order:

1. Read the actual version and current configuration.
2. Change only one setting relevant to this section.
3. Run a read-only or revocable request.
4. Check logs, exit codes, and final files.
5. Revert the previous modification if it fails.

1

Get-ChildItem -Force $env:USERPROFILE\.pi -ErrorAction SilentlyContinue

The completion criterion here is not that the interface appears, but that there are reproducible results for “Backup Boundaries of Pi Session Files”.

Immediately deactivate routing if reverse-generation authentication fails

1

caddy stop

Once the stop signal in the table appears, undo the changes in this section first and do not continue with subsequent automation.

Review the listening address after upgrade

Prepare a success sample and a failure sample around “Recheck listening address after upgrade”. Successful samples verify the normal path, and failed samples verify whether the restrictions really take effect.

1

Get-NetTCPConnection -LocalPort 30141 -ErrorAction SilentlyContinue

It is recommended to record the following four items:

• Pre-execution version or Git commit.
• Actual input, no secret value recorded.
• Observable output, status code or diff.
• Recovery actions and review results after recovery.

If the cause of the failure is still unclear, modify only one variable at a time; do not change the port, runtime, provider, and proxy at the same time.

Pi Web FAQ

Is it possible to skip the test environment and use Pi Web directly in the official project?

Not recommended. Complete at least one minimal success request, one intentional failure, and one recovery drill first.

Pi Web command can be run but the result is wrong, where to check first?

First check the input range, actual effective configuration and upstream response, and then check the model summary. A normal process does not mean that the business results are correct.

How to prevent Pi Web keys or tokens from entering Git?

Use system environment variables, secret management, or configuration files outside the project, and search the diff before committing. Keys must be rotated after a breach is discovered.

What is the most common thing to miss when upgrading Pi Web?

It is most easy to miss configuration format, default listening address, permission scope and cache compatibility. Save the version and verification samples before upgrading.

Pi Web acceptance issues

Upon completion you should be able to answer the following questions:

• Which exact version are you using?
• Which directories, ports, accounts and external services can be accessed?
• How to return the successful result to the original data or Git diff?
• When the upstream fails, will it report an error, retry, or switch?
• Is it possible that the key appears in logs or history?
• How to return to the pre-modification state within ten minutes?

If any of these cannot be answered, Pi Web is still in trial status and should not expand permissions or tap into production automation.