Use your own SSH server as a browser profile's proxy

Any server you can sign in to with SSH can act as a browser's proxy. The browser's connections travel inside the encrypted SSH connection to the server, and the server opens them onwards, so websites see the server's address instead of yours. It is the simplest way to give a browser profile a fixed exit you control: an office connection, a cloud server in a particular region, or a machine at a branch abroad.

This post explains how SSH tunnelling works, when your own server is the right exit, how to prepare the server and choose between a password and a key, why the server's host key matters, and how to set it up and check it in a browser profile.

How an SSH tunnel carries browser traffic

SSH (RFC 4251) is best known for remote shells, but the same connection can carry other traffic in channels. One channel type asks the server to open a TCP connection to a host and port on your behalf and pass the bytes back and forth (RFC 4254, section 7.2). This is what ssh -D uses to offer a local SOCKS proxy:

Point a browser at the SOCKS proxy on port 1080 of your own computer, and each page request becomes a channel inside the SSH connection. The website sees the server's address. Everything between your computer and the server is encrypted by SSH, whatever the site itself uses.

That command works, but it has to stay running in a terminal, it serves every application that finds the port, and nothing stops a profile from falling back to your own connection if it drops. A browser that speaks SSH itself removes all three problems.

When your own server is the right exit

Commercial proxies are usually the better choice when you need many addresses or addresses in many countries. Your own server is the better choice when:

• You need a fixed address someone has allowed. An admin panel, a partner portal or a firewall that only accepts the office's address.
• You already host in a region. A cloud server in Frankfurt gives a profile a Frankfurt exit you fully control.
• You want a dedicated address with a known history. Nobody else's traffic leaves from your own server.
• You work across offices. A small machine at a branch abroad gives profiles that branch's local connection.

Keep in mind how the exit looks: an address from a cloud provider belongs to a hosting network, and sites can tell, just as with datacenter proxies. An address at an office or a branch belongs to that office's internet provider. Our guide to residential, datacenter, ISP and mobile proxies covers how sites see each kind.

Prepare the server

1. Create a user just for the tunnel. Do not tunnel through an administrator account. A dedicated user with no special rights limits what a leaked credential could do.
2. Allow TCP forwarding for that user. OpenSSH allows it by default (AllowTcpForwarding yes in sshd_config). If your configuration turns it off, enable it for this user only with a Match User block.
3. Prefer key sign-in. Generate a key pair for the tunnel on your own computer and add the public key to the tunnel user's authorized_keys on the server:

1. Optionally restrict the key. In OpenSSH, prefixing the key's line in authorized_keys with restrict,port-forwarding turns off shells, agent forwarding and terminals for that key while keeping forwarding.
2. Note the server's host-key fingerprint. On the server, run the command below and keep the SHA256: value. You will compare it in the next step.

Password or private key?

Both work. A key is stronger: it cannot be guessed, it is never sent to the server, and you can revoke it by removing one line on the server without changing anyone's password. Protect the private key with a passphrase. Use a password only for a short test, and make it long and unique.

Why the host key matters

When an SSH client connects, the server proves its identity with its host key before you send any credential. The first time, you confirm the key's fingerprint; after that, the client remembers it and refuses a server that presents a different one. This is called pinning, and it is what stops someone between you and the server, on a café network or a misconfigured router, from posing as your server and collecting your password.

A proxy setup that skips this step sends your credentials to whatever answers at that address. Compare the fingerprint you noted on the server with the one your client shows before you confirm it.

How Browz uses an SSH server as a proxy

Browz has SSH built in as a proxy type, next to HTTP, HTTPS, SOCKS4 and SOCKS5, so there is no terminal to keep open and no local port for other applications to find (proxies).

• Password or private key. Sign in to the SSH server with a password, or with a private key and its passphrase.
• Host key confirmed, then pinned. Browz reads the server's host key first, sending no password or key, and shows its fingerprint for you to confirm. It then pins it, so a server presenting any other key is refused before your password or key is sent.
• Credentials sealed. Passwords and keys are encrypted at rest the moment you save them and are never shown again (security).
• DNS through the tunnel. Site names resolve at the SSH server, so your own network never sees which sites the profile visits.
• WebRTC handled for a TCP-only exit. SSH carries no UDP, so WebRTC is handled as for an HTTP proxy: the profile presents the measured exit address and sends no UDP outside the tunnel (WebRTC leaks explained).
• The exit measured, and the profile matched. Each check opens a real tunnel through the server and measures the exit over HTTPS; the profile's timezone and languages follow it.
• No fallback. If the tunnel cannot carry the exit lookup at Start, the profile is refused and never launches on your own connection.

Step by step in the app

1. Open Proxies and choose + SSH.
2. Enter the server's host, port (usually 22) and the tunnel user's name.
3. Choose password or private key. For a key, paste the private key (it begins with -----BEGIN OPENSSH PRIVATE KEY-----) and its passphrase.
4. Choose Fetch host key. Browz shows the key's algorithm and SHA256: fingerprint. Compare it with the value you noted on the server, and tick this is my server only if they match.
5. Choose Add SSH proxy, then Check on its row. The check shows the exit IP, country and city through the tunnel.
6. Assign the proxy to a profile in the new-profile panel or the profile drawer, or from the command line with browz update "<profile>" --proxy "<ssh-proxy-name>".
7. Leave the profile's timezone and languages empty so they follow the server's measured location.

If the check reports an error

• SSH authentication was rejected: the server refused the user name, password or key. Add the SSH proxy again with the right sign-in, and check that the public key is in the tunnel user's authorized_keys.
• SSH host-key verification failed: the server no longer presents the key you confirmed. Do not use it until the server's owner confirms the key changed, for example after a reinstall; then add the proxy again and confirm the new fingerprint.
• A connection error: check the host, port and any firewall in front of the server.

The full list is in fix a proxy that is not working, and the per-profile proxy guide covers assigning proxies across many profiles.

Frequently asked questions