How to SSH Into a Linux VM on an Intranet Using frp
I recently needed to access a Linux virtual machine remotely, but it didn’t have a public IP address. I decided to use frp (there are a few other ways), a reverse proxy tool that can forward SSH traffic through a server with a public IP address. This let me connect to the virtual machine without exposing it directly to the internet.
I downloaded the appropriate frp release for my operating system and CPU architecture from the GitHub releases page and extracted the frps and frpc binaries. The first one runs on the server with a public IP address, while the second runs on the machine I want to access.
Configure the frp server
I started by configuring frps, the server-side component. I created a file named frps.ini with the following settings:
[common]
bind_port = 10625
token = y9XBLEu2ymW1s5N3W7OuDPhUG4IohVmQ (hehe)
[common]
bind_port = 10625
token = y9XBLEu2ymW1s5N3W7OuDPhUG4IohVmQ (hehe)
The bind_port setting specifies the port that frps uses to accept connections from clients. The token setting provides a shared secret that the client must supply to authenticate with the server.
Configure the frp client
Next, I configured frpc on the Linux virtual machine. I created a file named frpc.ini with these settings:
[common]
server_addr = 100.26.xx.xxx
server_port = 10625
authentication_method = token
token = y9XBLEu2ymW1s5N3W7OuDPhUG4IohVmQ (hoho)
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 10626
[common]
server_addr = 100.26.xx.xxx
server_port = 10625
authentication_method = token
token = y9XBLEu2ymW1s5N3W7OuDPhUG4IohVmQ (hoho)
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 10626
The [common] section contains the connection details for the frp server. The server_addr and server_port settings specify its address and listening port, while authentication_method and token define how the client authenticates with it.
The [ssh] section defines the forwarding rule. I used type = tcp because SSH runs over TCP. The local_ip and local_port settings point to the SSH service running on the virtual machine, which listens on port 22 by default. Finally, remote_port = 10626 tells frps to expose the forwarded SSH connection on port 10626 of the public server.
Start the server and client
With both configuration files ready, I started frps on the public server:
./frps -c ./frps.ini
./frps -c ./frps.ini
I then configured the server’s firewall to allow incoming connections on ports 10625 and 10626. The first port is used for the frp client connection, and the second is where external SSH clients connect. The relevant firewall rules must permit these connections, along with any necessary cloud firewall or security group rules.
On the virtual machine, I started frpc:
./frpc -c ./frpc.ini
./frpc -c ./frpc.ini
The virtual machine also needs a running SSH server. If one isn’t installed, I installed and enabled the appropriate SSH server package for its Linux distribution before testing the connection.
Once frpc connected successfully to frps, I could access the virtual machine through the public server’s forwarded port. From my SSH client, I ran:
ssh ray@100.26.21.285 -p 10626
ssh ray@100.26.21.285 -p 10626
Here, ray is the username on the virtual machine, and 100.26.21.285 represents the public server’s address. These example addresses are placeholders and must be replaced with a valid public IP address. The address shown above is not a valid IPv4 address.
How the connection works
The setup works because frpc maintains a connection to frps over port 10625. When I connect to port 10626 on the public server, frps uses that existing connection to relay the SSH traffic to frpc, which forwards it to the virtual machine’s local SSH service on port 22.
The connection follows this path:
- The frpc client establishes a connection with frps on port 10625.
- My SSH client connects to port 10626 on the public server.
- frps relays the SSH traffic through the established client connection.
- frpc forwards the traffic to the virtual machine’s SSH service on
127.0.0.1:22. - The SSH session lets me operate the virtual machine remotely.
This approach works without assigning a public IP address to the virtual machine or configuring inbound port forwarding on its local network router. I only need a reachable public server running frps, a working SSH service on the virtual machine, and firewall rules that allow the required connections.
One security consideration is worth keeping in mind. A shared token helps authenticate frp clients, but it doesn’t replace SSH authentication or encryption… so be careful for anything sensitive.


