* [Connecting to frps via HTTP PROXY](#connecting-to-frps-via-http-proxy)
* [Connecting to frps via PROXY](#connecting-to-frps-via-proxy)
* [Client Plugins](#client-plugins)
* [Server Manage Plugins](#server-manage-plugins)
* [SSH Tunnel Gateway](#ssh-tunnel-gateway)
@ -510,6 +510,7 @@ includes = ["./confd/*.toml"]
```toml
# ./confd/test.toml
[[proxies]]
name = "ssh"
type = "tcp"
@ -621,6 +622,7 @@ The features are off by default. You can turn on encryption and/or compression:
```toml
# frpc.toml
[[proxies]]
name = "ssh"
type = "tcp"
@ -776,6 +778,7 @@ We would like to try to allow multiple proxies bind a same remote port with diff
```toml
# frpc.toml
[[proxies]]
name = "ssh"
type = "tcp"
@ -881,6 +884,7 @@ This feature is only available for types `tcp`, `http`, `tcpmux` now.
```toml
# frpc.toml
[[proxies]]
name = "test1"
type = "tcp"
@ -916,6 +920,7 @@ With health check type **tcp**, the service port will be pinged (TCPing):
```toml
# frpc.toml
[[proxies]]
name = "test1"
type = "tcp"
@ -935,6 +940,7 @@ With health check type **http**, an HTTP request will be sent to the service and
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "http"
@ -959,6 +965,7 @@ However, speaking of web servers and HTTP requests, your web server might rely o
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "http"
@ -975,6 +982,7 @@ Similar to `Host`, You can override other HTTP request headers with proxy type `
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "http"
@ -1002,6 +1010,7 @@ Here is an example for https service:
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "https"
@ -1024,6 +1033,7 @@ It can only be enabled when proxy type is http.
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "http"
@ -1048,6 +1058,7 @@ Resolve `*.frps.com` to the frps server's IP. This is usually called a Wildcard
```toml
# frpc.toml
[[proxies]]
name = "web"
type = "http"
@ -1067,6 +1078,7 @@ frp supports forwarding HTTP requests to different backend web services by url r
```toml
# frpc.toml
[[proxies]]
name = "web01"
type = "http"
@ -1152,6 +1164,7 @@ Using plugin **http_proxy**:
```toml
# frpc.toml
[[proxies]]
name = "http_proxy"
type = "tcp"
@ -1171,6 +1184,7 @@ Read the [document](/doc/server_plugin.md).
Find more plugins in [gofrp/plugin](https://github.com/gofrp/plugin).
### SSH Tunnel Gateway
*added in v0.53.0*
frp supports listening to an SSH port on the frps side and achieves TCP protocol proxying through the SSH -R protocol, without relying on frpc.
@ -1180,7 +1194,7 @@ frp supports listening to an SSH port on the frps side and achieves TCP protocol
sshTunnelGateway.bindPort = 2200
```
When running ./frps -c frps.toml, a private key file named .autogen_ssh_key will be automatically created in the current working directory. This generated private key file will be used by the SSH server in frps.
When running `./frps -c frps.toml`, a private key file named `.autogen_ssh_key` will be automatically created in the current working directory. This generated private key file will be used by the SSH server in frps.
frp supports listening on an SSH port on the frps side to achieve TCP protocol proxying using the SSH -R protocol. This mode does not rely on frpc.
SSH reverse tunneling proxying and proxying SSH ports through frp are two different concepts. SSH reverse tunneling proxying is essentially a basic reverse proxying accomplished by connecting to frps via an SSH client when you don't want to use frpc.
| autoGenPrivateKeyPath | string |Default value is ./.autogen_ssh_key. If the file does not exist or its content is empty, frps will automatically generate RSA private key file content and store it in this file.|No|
| authorizedKeysFile | string |Default value is empty. If it is empty, ssh client authentication is not authenticated. If it is not empty, it can implement ssh password-free login authentication. It can reuse the local /home/user/.ssh/authorized_keys file or a custom path can be specified.| No |
### Basic Usage
#### Server-side frps
Minimal configuration:
@ -36,26 +35,27 @@ Minimal configuration:
sshTunnelGateway.bindPort = 2200
```
Place the above configuration in frps.toml and run ./frps -c frps.toml. It will listen on port 2200 and accept SSH reverse proxy requests.
Place the above configuration in frps.toml and run `./frps -c frps.toml`. It will listen on port 2200 and accept SSH reverse proxy requests.
Note:
1. When using the minimal configuration, a .autogen_ssh_key private key file will be automatically created in the current working directory. The SSH server of frps will use this private key file for encryption and decryption. Alternatively, you can reuse an existing private key file on your local machine, such as /home/user/.ssh/id_rsa.
1. When using the minimal configuration, a `.autogen_ssh_key` private key file will be automatically created in the current working directory. The SSH server of frps will use this private key file for encryption and decryption. Alternatively, you can reuse an existing private key file on your local machine, such as `/home/user/.ssh/id_rsa`.
2. When running frps in the minimal configuration mode, connecting to frps via SSH does not require authentication. It is strongly recommended to configure a token in frps and specify the token in the SSH command line.
1. --proxy_name is optional, and if left empty, a random one will be generated.
The username for logging in to frps is always "v0" and currently has no significance, i.e., v0@{frps_address}.
2. The server-side proxy listens on the port determined by --remote_port.
3. {tcp|http|https|stcp|tcpmux} supports the complete command parameters, which can be obtained by using --help. For example: ssh -R :80::8080 v0@127.0.0.1 -p 2200 http --help.
4. The token is optional, but for security reasons, it is strongly recommended to configure the token in frps.
1. `--proxy_name` is optional, and if left empty, a random one will be generated.
2. The username for logging in to frps is always "v0" and currently has no significance, i.e., `v0@{frps_address}`.
3. The server-side proxy listens on the port determined by `--remote_port`.
4. `{tcp|http|https|stcp|tcpmux}` supports the complete command parameters, which can be obtained by using `--help`. For example: `ssh -R :80::8080 v0@127.0.0.1 -p 2200 http --help`.
5. The token is optional, but for security reasons, it is strongly recommended to configure the token in frps.
During the SSH protocol handshake, public keys are exchanged for data encryption. Therefore, the SSH server on the frps side needs to specify a private key file, which can be reused from an existing file on the local machine. If the privateKeyFile field is empty, frps will automatically create an RSA private key file.
#### Specifying the Auto-Generated Private Key File Path
frps will automatically create a private key file and store it at the specified path.
Note: Changing the private key file in frps can cause SSH client login failures. If you need to log in successfully, you can delete the old records from the /home/user/.ssh/known_hosts file.
Note: Changing the private key file in frps can cause SSH client login failures. If you need to log in successfully, you can delete the old records from the `/home/user/.ssh/known_hosts` file.
#### Using an Existing authorized_keys File for SSH Public Key Authentication
@ -146,11 +143,10 @@ The authorizedKeysFile is the file used for SSH public key authentication, which
If authorizedKeysFile is empty, frps won't perform any authentication for SSH clients. Frps does not support SSH username and password authentication.
You can reuse an existing authorized_keys file on your local machine for client authentication.
You can reuse an existing `authorized_keys` file on your local machine for client authentication.
Note: authorizedKeysFile is for user authentication during the SSH login phase, while the token is for frps authentication. These two authentication methods are independent. SSH authentication comes first, followed by frps token authentication. It is strongly recommended to enable at least one of them. If authorizedKeysFile is empty, it is highly recommended to enable token authentication in frps to avoid security risks.
#### Using a Custom authorized_keys File for SSH Public Key Authentication
Specify the path to a custom authorized_keys file.
Specify the path to a custom `authorized_keys` file.
Note that changes to the authorizedKeysFile file may result in SSH authentication failures. You may need to re-add the public key information to the authorizedKeysFile.
fatedier
12 months ago
committed by