[GH-ISSUE #2186] 不知道这是不是一个bug #1741

New issue

Closed

opened 2026-05-05 13:07:11 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 13:07:11 -06:00

Owner

Originally created by @holyshete on GitHub (Jan 12, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2186

服务端的frps.ini的写法为:
[common]
bind_port = 7000

客户端的frpc.ini的写法为：
[common]
server_addr = xx.xx.xx.xx
server_port = 7000

[ssh_org]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 17022

在几个月的使用中没出现什么问题
但是前两天，发生了虽然显示frp连接成功但是无法进行ssh连接的情况
2021/01/12 15:21:44 [I] [service.go:288] [99f48d633ea5ec03] login to server success, get run id [99f48d633ea5ec03], server udp port [0]
2021/01/12 15:21:44 [I] [proxy_manager.go:144] [99f48d633ea5ec03] proxy added: [ssh_org]
2021/01/12 15:21:44 [I] [control.go:180] [99f48d633ea5ec03] [ssh_org] start proxy success

这里我进行了一系列的排查。
服务端与用户端都没有防火墙，服务端的17022端口能够ping通，用户端的22端口能够直接使用putty之类的软件进行连接。
希望您能够给予相关的情况的指导。

Originally created by @holyshete on GitHub (Jan 12, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2186 服务端的frps.ini的写法为: [common] bind_port = 7000 客户端的frpc.ini的写法为： [common] server_addr = xx.xx.xx.xx server_port = 7000 [ssh_org] type = tcp local_ip = 127.0.0.1 local_port = 22 remote_port = 17022 在几个月的使用中没出现什么问题但是前两天，发生了虽然显示frp连接成功但是无法进行ssh连接的情况 2021/01/12 15:21:44 [I] [service.go:288] [99f48d633ea5ec03] login to server success, get run id [99f48d633ea5ec03], server udp port [0] 2021/01/12 15:21:44 [I] [proxy_manager.go:144] [99f48d633ea5ec03] proxy added: [ssh_org] 2021/01/12 15:21:44 [I] [control.go:180] [99f48d633ea5ec03] [ssh_org] start proxy success 这里我进行了一系列的排查。服务端与用户端都没有防火墙，服务端的17022端口能够ping通，用户端的22端口能够直接使用putty之类的软件进行连接。希望您能够给予相关的情况的指导。

gitea-mirror

2026-05-05 13:07:11 -06:00

closed this issue
added the
lifecycle/stale

WaitingForInfo
labels

gitea-mirror commented

2026-05-05 13:07:14 -06:00

Author

Owner

@yuyulei commented on GitHub (Jan 15, 2021):

该日志只是显示“管道”已经建立，而你具体一次 ssh 是一个请求，关于该请求的日志上面并没有提供。
所以希望提供：

“在几个月的使用中没出现什么问题” 到“无法进行ssh连接”之间，确认没有做过变更？
是用什么命令尝试 ssh 连接？
“无法进行ssh连接”时，显示了什么错误（工具和 frp）？

@yuyulei commented on GitHub (Jan 15, 2021): 该日志只是显示“管道”已经建立，而你具体一次 ssh 是一个请求，关于该请求的日志上面并没有提供。所以希望提供： 1. “在几个月的使用中没出现什么问题” 到“无法进行ssh连接”之间，确认没有做过变更？ 2. 是用什么命令尝试 ssh 连接？ 3. “无法进行ssh连接”时，显示了什么错误（工具和 frp）？

gitea-mirror commented

2026-05-05 13:07:15 -06:00

Author

Owner

@holyshete commented on GitHub (Jan 18, 2021):

您好，谢谢您能给予我反馈
回答：
1、从系统设定上应该没有做出什么变更
2、通过putty以及服务器的ssh命令都尝试过
3、通过putty使用会显示 Network error:Connect timed out，之前我检查过服务器allow与deny用户名单是没有问题的。
通过ssh debug进行查看：
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "xx.xx.xx.xx" port 17022
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 17022.
debug1: connect to address xx.xx.xx.xx port 17022: Connection timed out
ssh: connect to host xx.xx.xx.xx port 17022: Connection timed out

@holyshete commented on GitHub (Jan 18, 2021): 您好，谢谢您能给予我反馈回答： 1、从系统设定上应该没有做出什么变更 2、通过putty以及服务器的ssh命令都尝试过 3、通过putty使用会显示 Network error:Connect timed out，之前我检查过服务器allow与deny用户名单是没有问题的。通过ssh debug进行查看： OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "xx.xx.xx.xx" port 17022 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to xx.xx.xx.xx [xx.xx.xx.xx] port 17022. debug1: connect to address xx.xx.xx.xx port 17022: Connection timed out ssh: connect to host xx.xx.xx.xx port 17022: Connection timed out

gitea-mirror commented

2026-05-05 13:07:16 -06:00

Author

Owner

@yuyulei commented on GitHub (Jan 27, 2021):

确认下访问 frps:17022 是否通畅？然后你每次尝试 ssh frps:17022 的时候，frps 有日志吗？

@yuyulei commented on GitHub (Jan 27, 2021): 确认下访问 frps:17022 是否通畅？然后你每次尝试 ssh frps:17022 的时候，frps 有日志吗？

gitea-mirror commented

2026-05-05 13:07:16 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 14, 2021):

Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Mar 14, 2021): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.