SSH IP Allowlist from a Phone: Fix Changing Mobile IPs

To use an SSH IP allowlist from a phone, connect through Tailscale or a gateway with a fixed public IP. Allowing your current cellular address is only temporary. With TermAI’s built-in Tailscale, you can reach a server’s private address without updating firewall rules whenever your mobile network changes.

Why does SSH work on Wi-Fi but fail on mobile data?

A source-IP allowlist checks the address arriving at the server. Your home connection and your cellular connection can present different addresses, so a rule that admits one can reject the other before SSH authentication starts.

Your phone’s Wi-Fi settings show a local address. Reserving that address on your router does not reserve the public address seen by a remote VPS. On cellular IPv4, carrier-grade NAT can also put multiple subscribers behind a shared public address. That limits how precisely an IP identifies a person or device. RFC 6269 explains address-sharing implications.

IPv6 requires separate attention: a connection may use a global IPv6 address instead of the IPv4 address you allowed. Temporary IPv6 addresses can rotate, so a single-address rule may later become stale. Rotation is a defined privacy mechanism, not a broken SSH client. RFC 8981 describes temporary IPv6 addresses.

A timeout is a clue, not proof of an allowlist problem. A wrong destination, unavailable server, blocked outbound port, or broken VPN route can look similar. Compare the saved host, address family, and network path before changing credentials. For broader diagnosis, see SSH connection timed out.

How can I SSH from a phone when my IP keeps changing?

Choose based on which part of the network you control:

A private route is a good fit for a server you administer. A fixed public gateway fits an external service whose firewall you cannot redesign. Both retain a network restriction while removing the dependency on your phone’s current public IP.

How do I use TermAI with Tailscale instead of a public IP allowlist?

TermAI is an SSH/SFTP app for iOS and Android with Tailscale built in. For this workflow, use ordinary SSH over Tailscale: the private network provides reachability, and your SSH server still checks your username and key.

1. Join the server to your tailnet. Install Tailscale using its instructions for that operating system, authorize the server, and keep the existing management route available.
2. Connect TermAI to the same tailnet. Use its built-in Tailscale integration and complete the required account or device approval.
3. Get the server’s private address. On a Linux server with Tailscale installed, run tailscale ip -4. Copy that result into TermAI’s SSH host field. Use the server’s actual SSH port, username, and authorized key.
4. Verify the host key. A private address may be a new saved destination. Compare its fingerprint through a trusted server console or existing verified connection before accepting it.
5. Test a fresh login on cellular. Turn Wi-Fi off and reconnect to that same private address before removing public access.

Tailscale addresses remain stable as devices move between networks. They are not immutable: removing or resetting a node, or an administrator changing its address, can require updating a saved connection. Tailscale documents address assignment and changes.

Restrict tailnet policy to the intended administrators and target SSH port. Check for existing broad grants: adding a narrower grant does not cancel another rule that already allows access. Tailscale’s grants reference explains additive permissions.

You do not need to enable the separate Tailscale SSH authentication feature just to solve changing public IPs. Keeping normal SSH authentication makes the migration easier to inspect. The full Tailscale setup guide explains the two modes.

TermAI’s SFTP can use the same reachable server and SSH credentials, subject to the server’s SFTP configuration. This gives you a route for checking logs and transferring files from either mobile platform without repeatedly editing public-IP rules.

Where should I restrict SSH access?

There can be several independent gates. Changing one does not update the others.

For direct public SSH, AWS documents source rules using the connecting machine’s public address or an appropriate range. Do not put a phone’s private tailnet address into that public-path rule and expect it to route over the internet. AWS security-group reference.

On an Ubuntu host that already uses UFW, this is an additive allowance, assuming SSH listens on TCP port 22:

sudo ufw status verbose
sudo ufw status numbered
sudo ufw allow in on tailscale0 to any port 22 proto tcp

This does not, by itself, make SSH private. Existing public allowances and the default policy still matter. Identify and remove obsolete SSH allowances only after testing the private route. Preserve required web and application access. Tailscale’s Ubuntu lockdown guide provides the broader sequence.

Also, UFW’s displayed rules are not the complete Tailscale access policy. Tailscale can install its own netfilter rules ahead of other rules. Enforce who can connect through tailnet policy, and test an unauthorized device rather than assuming a narrow UFW source rule limits every tailnet peer. Tailscale netfilter modes.

For OpenSSH, AllowUsers user@host can restrict source hosts, including CIDR addresses. Review these restrictions when changing routes; validate configuration with sudo sshd -t before reloading the appropriate SSH service. OpenSSH configuration manual.

Avoid copying legacy /etc/hosts.allow recipes into a modern setup: upstream OpenSSH removed TCP Wrappers support in version 6.7. OpenSSH release notes.

What if my server requires a fixed public source IP?

Use a controlled gateway with a reserved public address, and send the target’s SSH traffic through it:

Phone on Wi-Fi or cellular
  -> authenticated VPN gateway
  -> reserved public egress IP
  -> server's SSH allowlist

A Tailscale exit node is one possible gateway. Ordinary tailnet connectivity does not change public internet traffic; selecting an exit node provides that different route. A home exit node with a changing ISP address still has a changing public source IP. Tailscale exit-node documentation.

TermAI’s built-in Tailscale is not a promise of fixed public egress. Configure that route in a supported VPN client or networking setup, and verify that TermAI’s actual SSH connection uses it. An IP-check website in a browser can take a different route because of proxies or app-specific routing.

Once connected to a normal OpenSSH server, run this in the remote shell:

printf '%s\n' "$SSH_CONNECTION"

The fields are client address, client port, server address, and server port. The first field tells you the immediate source observed by that SSH server; through a gateway or bastion, expect the relevant gateway-side address. If the variable is unavailable, inspect server connection logs through your console. OpenSSH’s environment reference.

A bastion provides a different route: the phone authenticates to the bastion, which connects onward to the target. Allow the source the target actually sees, which might be private within a cloud network. Verify your client’s jump-host support before relying on this workflow; do not assume TermAI implements every desktop ProxyJump option.

If your organization uses a managed access proxy, follow its IAM and client requirements. For an AWS-specific starting point, see SSH into EC2 from a phone.

Can dynamic DNS or a script update my SSH allowlist?

Yes, if your firewall supports the necessary update mechanism. But DDNS alone does not update a source-IP rule. Giving a changing server address a hostname solves destination discovery. Tracking a changing client source requires the firewall to refresh that hostname or an authenticated service to rewrite its address rules.

For temporary public access:

• Determine the source address for the actual SSH path, including whether it uses IPv4 or IPv6.
• Add only that address: /32 for a single IPv4 address or /128 for a single IPv6 address.
• Add the new allowance before removing the old one, then test a fresh connection.
• Expire temporary rules and remove stale entries.
• Keep the update mechanism reachable independently of SSH, with credentials limited to the necessary firewall changes.

A script running on the remote server and checking its own public IP discovers the server’s egress, not the phone’s. A phone-side background updater can miss a network change or stop when the OS suspends it. An updater that needs the blocked SSH connection to repair access cannot recover you.

Do not widen the rule to an entire carrier or country just to avoid updates. That admits unrelated users and offers no assurance about the next Wi-Fi network. Even a correct narrow allowlist remains an additional filter; retain SSH keys and appropriate account permissions.

How do I change SSH rules without locking myself out?

Start while you still have working access. Confirm that the provider console or another independent recovery route actually opens, and record the current firewall rules.

In TermAI, ask the AI assistant for inspection commands first:

I am moving this Ubuntu server from public SSH to SSH over Tailscale. Suggest read-only checks for the SSH listening port, UFW rules, and current connection source. Explain the output; do not suggest deleting rules yet.

TermAI suggests commands and waits for your confirmation before execution. Review the host, interface, port, and addresses yourself. The assistant cannot infer an unseen cloud firewall or guarantee that a proposed rule preserves access.

After establishing the private route, use this acceptance checklist:

1. Open a new TermAI connection to the private server address on Wi-Fi.
2. Switch to cellular and open another new connection. Do not rely solely on an existing shell surviving.
3. Verify the observed source and, if needed, test an SFTP directory listing.
4. Remove obsolete public SSH allowances in the host and cloud firewalls, covering both address families. Retain networking needed for Tailscale to operate; consult its firewall requirements for restricted networks.
5. Confirm that the private login still succeeds, the disallowed public path fails, and an unauthorized tailnet device cannot log in through the private path.

Keep recovery access available throughout. If access fails, restore the relevant rule from the console using the SSH lockout recovery guide.

For daily use, save the verified private connection in TermAI and practice reconnecting before you need it during an incident. The free tier includes unlimited SSH/SFTP and five AI requests per day; the assistant is available for command suggestions when typing a long diagnostic command on a phone is awkward.

What else should I know about mobile SSH allowlists?

Can I give my phone a static IP for SSH?

A static Wi-Fi address only applies on that local network. For roaming access, use a stable Tailscale address or route SSH through a controlled gateway with a reserved public IP. Ask your carrier about static public addressing only if you specifically need that service.

Is it safe to allowlist my carrier’s entire IP range?

It admits other customers using that range and still may not cover your next network. Prefer a private network or controlled gateway, and retain SSH key authentication.

Does built-in Tailscale give TermAI a static public IP?

No. Tailscale provides private network connectivity. A fixed public source IP requires a separately configured static egress route; joining a tailnet alone does not provide one.

Will SSH stay connected when I switch from Wi-Fi to cellular?

The private route avoids rewriting the public-IP allowlist, but an uninterrupted session is not guaranteed. Network outages or mobile app suspension can require reconnection; use a server-side session manager for long-running work.

Does SFTP need a separate IP allowlist?

When SFTP uses the same SSH server and port, it follows the same network rules. It still requires server-side SFTP support and appropriate file permissions.