这是一个创建于 1460 天前的主题，其中的信息可能已经有所发展或是发生改变。
去掉前奏直接来：
1 、在 vps 对应管理端在安全组中拒绝 22 端口访问
2 、使用端口反弹工具进行反向连接访问
- 访问路径：sshclient-》 proxy-〉 vps 反向连接隧道-》 vps localhost：22
- 反向隧道工具有很多选择，按个人喜好。推荐一个自撸工具 sg：github.com/lazy-luo/smarGate
如此可以做到:无法直接访问 vps，使用自己的代理可以访问
第 1 条附言 · 2020-11-24 00:33:39 +08:00
附上自己的使用方式：
1 、手机上有 proxy
2 、vps 上启动 proxy 但只外连不监听
3 、两个 proxy 最终会以 tcp 方式建立 p2p 隧道（通过第三方服务器协商地址）
4 、电脑 ssh 客户端访问手机 proxy，通过隧道访问 vps 上 localhost：22
ps：以透明代理方式访问，因此会在隧道中进行正常 ssh 握手（隧道为普通 tcp 连接）
好处：
1 、vps 上没有任何监听端口对外服务，除了 ddos 外，安全坚固
2 、手机网络是私有网络，安全
3 、带着手机，随时随地访问服务器
1 、手机上有 proxy
2 、vps 上启动 proxy 但只外连不监听
3 、两个 proxy 最终会以 tcp 方式建立 p2p 隧道（通过第三方服务器协商地址）
4 、电脑 ssh 客户端访问手机 proxy，通过隧道访问 vps 上 localhost：22
ps：以透明代理方式访问，因此会在隧道中进行正常 ssh 握手（隧道为普通 tcp 连接）
好处：
1 、vps 上没有任何监听端口对外服务，除了 ddos 外，安全坚固
2 、手机网络是私有网络，安全
3 、带着手机，随时随地访问服务器
 |
1
boris93 2020-11-23 12:27:48 +08:00 via Android  2
but why?
复杂密码，或者证书，已经可以实现足够的安全性 还不够的话可以改掉端口，这就足以挡掉那些自动扫描脚本了 |
 |
2
wslzy007 OP 1
强密码证书类的挡不住软件漏洞
其实这是个通用思路，关键是将私有服务器的公共访问私有化，等同于内网访问，提升安全级别 |
 |
3
deorth 2020-11-23 12:57:54 +08:00
其实就是多加了一层认证手段
我用类似的方法来访问 web/rdp/vnc 等弱密码保护的服务，但是 ssh 就没有用，原因同#1，ssh 安全性经过合适的配置后，已经够强了 |
 |
4
oxromantic 2020-11-23 13:00:15 +08:00
实用性很低，不如只开放 22 端口给自己的 ip，别和我说这个也有漏洞，这个漏洞比你用反向隧道漏洞几率小多了
|
 |
6
sagaxu 2020-11-23 13:03:52 +08:00 via Android 3
端口敲门了解一下
|
|
7
boris93 2020-11-23 13:07:27 +08:00 via Android
怕软件漏洞那就封锁所有入站连接吧
别的东西也有漏洞 |
|
8
wslzy007 OP 仁者见仁吧，安全的事，你要没摊上那永远就是别人的事。。。
网络远程攻击 /渗透主要是钉的蛋壳上的缝，对于部分私有应用，完全可以只监听 localhost，去掉对外监听也就断了被攻击的路 漏洞的事不谈也罢，毕竟过于触目惊心 |
|
11
wslzy007 OP 本帖是有感而发，源自“小米内网穿透事件”的帖子，对于个人而言比较推崇“内网”到“内网”的安全访问。
|
 |
12
locoz 2020-11-23 13:26:49 +08:00 via Android
说白了这就跟用 zerotier 或其他 VPN 工具连接没啥差别，而且还更麻烦些
|
|
13
wslzy007 OP |
 |
14
chengzi168 2020-11-23 13:31:55 +08:00 via Android
忍不住小声问一句，SSH 是哪几个单词的缩写。。。
|
|
15
deorth 2020-11-23 13:52:05 +08:00
@Jirajine 之前用了一段时间的 ssh 转发端口，但是并不方便，需要针对每一个端口起一个 ssh 进程，还会经常断开。目前使用 v2ray 转发端口，web 类的服务则不需要转发端口，访问时走 socks5/http 代理即可，只需要在客户端侧的内网中有一个 v2ray 进程，还可通过旁路由+透明代理实现客户端机器无需配置，这都是 ssh 转发无可比拟的
|
 |
16
xuanbg 2020-11-23 14:12:02 +08:00
白名单最安全，又简单。
|
 |
17
webshe11 2020-11-23 14:12:12 +08:00 via Android
@chengzi168 secure shell
|
 |
18
DoctorCat 2020-11-23 14:16:05 +08:00
你这个方案太麻烦了， 我目前在用 autossh + 腾讯云，足以解决问题。安全可以充分利用安全组策略，放你自己的 IP 白名单
|
 |
19
Maboroshii 2020-11-23 14:16:33 +08:00
proxy 被破了怎么办？ 中间这么长一串不还是相当于透明代理么，不明白意义在哪。除非改成私有协议
|
|
20
wslzy007 OP |
 |
21
luoleng 2020-11-23 14:32:24 +08:00
有点看不懂，proxy 无对外服务端口的话，还可以访问？
|
 |
23
natashahollyz 2020-11-23 14:41:25 +08:00
改端口，秘钥，白名单，足够了。不需要那么复杂
|
 |
25
Mashirobest 2020-11-23 14:55:42 +08:00 via Android
不太需要，安全和便利很多情况下是相冲突的，我认为白名单加证书够我用了，太复杂我都懒得登上去🙃
|
 |
26
zro 2020-11-23 14:59:00 +08:00
我就暴露 VPN 端口，开机自动连接，如果连不上，再用网页端 SSH 上去查。。
 |
 |
27
Te11UA 2020-11-23 15:14:01 +08:00
大可不必，改端口用公钥就可以了
|
 |
28
Caan07 2020-11-23 15:24:22 +08:00
其实，改了端口，用公钥，禁止账号已经适用大部分人。因为如果真的是系统和常用软件的问题，沦陷的就不只是你了。
其实限制 IP 也可以增加安全系数，但如果他不是固定 IP，又要增加难度了。 |
 |
29
firefox12 2020-11-23 15:30:20 +08:00 1
什么意思？ 你本地 ssh client 连 proxy, proxy 搭建在那里？ vps 上面？ 通过 proxy 反向连 vps 的 127.0.0.1 ??
|
 |
30
doveyoung 2020-11-23 15:34:59 +08:00
改端口，禁密码，加防火墙，求你来打我……
当然不是说万无一失，只是攻击成本那么高，何必针对我一个小小主机呢，去搞大厂的不好吗 |
 |
31
VgV 2020-11-23 15:46:14 +08:00
@Caan07 我以前也是改端口用公钥，再加限制 IP，用 sh 脚本 ping 某个指定域名得 IP 加白，比如花生壳，然后绑定在路由器上。。后来觉得太麻烦了，就只改端口用公钥了。
|
 |
32
opengps 2020-11-23 15:53:33 +08:00
其实，我用过的最安全的，还是以前的物理机房时候的用 vpn 拨入内网再内网管控。只有对外业务端口是开放的，任何管理端口都用 vpn 拨入后才能走内网连接上
注意我说的 vpn 不是帖子里常见的 vpn 的用法。 |
 |
33
jisibencom 2020-11-23 16:03:11 +08:00
这种需要注册需要第三方的不可靠。
|
 |
34
hzqim 2020-11-23 16:14:31 +08:00
fail2ban+白名单。
|
 |
35
CSM 2020-11-23 16:17:46 +08:00 1
楼主标题写反了 /doge
ssh：一种安全访问 vps 的方法 |
 |
36
lbyo 2020-11-23 16:27:59 +08:00
|
 |
37
msg7086 2020-11-23 16:42:49 +08:00
大公司有 VPN 做管控，小公司的话正常配置好的 ssh 就一把梭了。
实在怕的话可以配置端口敲门。 |
 |
38
mytsing520 2020-11-23 17:07:27 +08:00
为了安全考虑，我不会加个堡垒机么
|
 |
39
parametrix 2020-11-23 17:18:41 +08:00 1
防火墙白名单之类的方案不解决链路上的中间人攻击。
各种改端口对一些机器扫描有作用，但对稍微认真点的攻击者没有意义，端口毕竟就那么多。 整这些还不如老实把 SSH 配置好，私钥登陆并限制 root 账户。SSH 算得上是最被长时间广泛使用、审计的软件之一了，没有正确的私钥根本连链接都无法完整建立，安全性绝对不会输给流行浏览器 TLS 的实现。说白了 SSH 的密码学实践的可靠程度碾压各路 VPN，只要配置得当，我认为没有画蛇添足的必要。Github 全站仓库权限依赖 ssh，也没听说谁的仓库因为 ssh 漏洞出问题。 |
 |
41
eason1874 2020-11-23 17:45:58 +08:00
我的做法跟 #18 楼类似，通过安全组 API 自动设置白名单，连接的时候才打开端口，不连的时候连端口都不开，避免流量骚扰。
|
 |
42
andyliu24 2020-11-23 20:01:59 +08:00
特定 IP 放行不行吗？为什么要反向隧道……
|
 |
43
l4ever 2020-11-23 20:04:27 +08:00
搞这么麻烦,
port knocking 或者 2fa 不香? |
|
44
firefox12 2020-11-23 20:06:10 +08:00
我觉得他的想法是 ssh 的端口 外面用户可以连上不安全，所以放在 127 上面 然后利用 proxy 来连，ssh 是安全了， 你的 proxy 安全吗？ 你的 proxy 被 ddos 了，你连 ssh 都没机会连了。ssh 的安全防护 在 proxy 上不得都来一次? 你的 proxy 的加密方式比 ssh 的好？ 你和 proxy 的通讯又是一种裸奔。
|
 |
45
mxT52CRuqR6o5 2020-11-23 20:10:45 +08:00
直接设置白名单一样效果，根本不需要什么反弹工具
|
|
46
mxT52CRuqR6o5 2020-11-23 20:11:41 +08:00
而且操作不好或者被攻击还会有无法访问的风险
|
|
47
chengzi168 2020-11-23 20:17:51 +08:00 via Android
@lbyo 看来没 get 到点。SSH secure shell，人家本来就是安全的 shell，自带一堆可以提高安全的工具，为啥还要自己造个轮子。
|
 |
48
smilingsun 2020-11-23 20:47:00 +08:00
|
 |
49
love 2020-11-23 21:23:35 +08:00 via Android
先想想你的服务器数据有没有 ssh 0day 有价值
|
 |
50
K4 2020-11-23 23:38:48 +08:00 via iPhone
也就是说把“ssh 的安全风险”转嫁到了一个“端口反弹工具”上？你确定这个“端口反弹工具”比 ssh 还安全？
|
|
51
K4 2020-11-23 23:42:25 +08:00 via iPhone
|
 |
53
imycc 2020-11-24 00:11:42 +08:00
改端口，端口白名单只开放给堡垒机，堡垒机通过 VPN 连，VPN 和堡垒机的登录用 MFA 验证
禁密码登录，生成私钥的时候强制用复杂密码（防止修电脑泄露） 做到这样就足够了吧。担心 SSH 的漏洞还不如搞好服务器的白名单管理，别什么乱七八糟的服务都开到外网 |
 |
54
akira 2020-11-24 00:22:50 +08:00
以前也有过同样的想法。
|
|
55
wslzy007 OP @firefox12
自己的使用方式是： 1 、手机上有 proxy 2 、vps 上启动 proxy 但只外连不监听 3 、两个 proxy 最终会以 tcp 方式建立 p2p 隧道（通过第三方服务器协商地址） 4 、电脑 ssh 客户端访问手机 proxy，通过隧道访问 vps 上 localhost：22 ps：以透明代理方式访问，因此会在隧道中进行正常握手（隧道为普通 tcp 连接） 好处： 1 、vps 上没有任何监听端口对外服务，除了 ddos 外，安全坚固 2 、手机网络是私有网络，安全 3 、带着手机，随时随地访问服务器 |
 |
57
GeruzoniAnsasu 2020-11-24 01:08:18 +08:00 2
.................. 为什么总有人以为自己机子被日了是 ssh 的原因
绝大多数入侵都不是从 ssh 进去的 |
 |
58
no1xsyzy 2020-11-24 01:19:24 +08:00
建议学习 linus 定律：足够多的眼睛，就可让所有问题浮现
拿大教堂与集市的比喻来说，名不见经传的业余人士构造的私有协议和私有实现基本就跟创建兄弟会差不多。 |
 |
59
yjd 2020-11-24 01:51:21 +08:00 via Android
我没记错的话，几年前有个啥公司，就是公司员工凭据被盗，导致全被拿下。好像是方程组？
你中间转发的代理机，web （如果有），客户端。可突破的点又不只一个 |
 |
60
secondwtq 2020-11-24 02:09:02 +08:00
前段时间在 GitHub 上看到个项目： https://github.com/skeeto/endlessh
大致思路是故意打开 22 端口，并且接受所有连接，但是不进行真实的数据交换，就在那拖着 |
 |
61
ruidoBlanco 2020-11-24 06:15:23 +08:00 1
闲得蛋疼。禁用密码登录，fail2ban，禁止 root 登录，我这么用了十几年屁事没有。
|
|
62
mytsing520 2020-11-24 07:14:38 +08:00
@K4 233333
|
|
63
deorth 2020-11-24 07:35:37 +08:00
@no1xsyzy 最早没有 shadowsocks 的时候大家都是用这种方法科学上网的，为什么发明了 ss/ssr，再到 v2ray，因为需求是在增长的。我现在的需求早就不是一个转发的 socks5 代理能解决的了（何况据说这玩意还容易导致你的 VPS 被墙，反正我是不敢多用）
|
 |
64
learningman 2020-11-24 09:12:19 +08:00
@oxromantic 什么叫做自己的 IP 。。。家宽 IP 会换，如果是另外一台服务器的话，一是麻烦，二是那台忘记续费了两边一起炸
|
|
66
no1xsyzy 2020-11-24 09:21:13 +08:00
@learningman 有一种方式 IP 变动就登控制台改安全组。
|
 |
68
owt5008137 2020-11-24 09:32:19 +08:00 via Android
搞得好像 ssh 有漏洞，代理软件就没漏洞一样。
|
|
69
wslzy007 OP 有明白人，也不缺杠精
安全没有绝对，之前说过了，试图探讨一种针对私有资源通用的安全解决方案（ ddos 攻击不讨论），重点就 3 个： 1 、vps 主机关闭所有对外监听 2 、在 1 ）这个约束下想办法让自己能够访问 3 、进一步思考如何保证只有自己能访问 |
 |
70
NilChan 2020-11-24 09:44:15 +08:00 via Android
服务提供商不是都提供 web console 吗？偏要干的话，关闭全部端口，只用 web console 就行了。
|
 |
71
Felldeadbird 2020-11-24 10:06:40 +08:00
思路是不错，但是还不如做一台中转机。 用的时候才开启 中转机。然后内网连接 目标服务器。
在刺激点，外网服务器反代内网目标服务器。 这样外网服务器就是被黑了。我换一台反代就可以了。 |
 |
72
moonfly 2020-11-24 10:12:20 +08:00
顺带歪个楼；
虽然还没用过 lz 写的 SG 工具，但看到 lz 的功能介绍，让我想到了我前公司的一款产品； 部署在客户内网的一台定制化 Linux 系统，不对公网开放任何端口；但 web 管理界面上提供原厂在线技术支持服务； 客户点击发起远程支持后，系统底层就起一个 ssh 的反向 tunnel 连回到公司的服务器并获取一个 ticket， 我们售后工程师通过这个 ticket 在公司的服务器上获取对应客户反向连接的随机分配端口号，直接 ssh 就可以登录客户内网的系统上处理问题了； 所以我觉得 ssh 真的是又安全又强大； ssh -L 、ssh -R 、ssh -D 菜刀 3 连，简直是渗透神器！ |
|
73
wslzy007 OP @moonfly 思路上是契合的
差异在于（同样的场景为例）： 1 、sg 无需在定制化 linux 中运行，任意一台内网设备即可。不依赖 ssh，仅仅单纯提供安全隧道 2 、sg 无需获取 ticket，依赖用户登录会话进行识别，完整的用户间隔离 3 、远程支持的随机端口是在客户端按需配置的，客户端为手机移动 app |
 |
74
Tonni 2020-11-24 11:20:57 +08:00
我就是使用类似的思路来访问家里的网络的，内网里只通过 frp 暴露出来一个 aes-256-gcm 协议的 ss 代理，然后访问内网的请求都走这个代理。现在无论 clash 还是 surge 都支持通过域名访问特定的代理，比直接暴露服务出来安全多了。
|
 |
76
nmap 2020-11-24 11:51:36 +08:00
换个思路吧：ssh 端口日常是关闭的，按需开放，比你那个简单可靠多了
|
 |
78
kestrelBright 2020-11-24 15:00:11 +08:00
@nmap +1
|
 |
80
cwyalpha 2020-11-25 10:49:38 +08:00 via iPhone
ssh 就默认的 22 口令复杂点 加个 fail2ban
主要的问题还是其他服务，netstat 看看开了哪些口对应哪些服务，还有没弱口令，定期修洞。 |
 |
81
impig33 2021-05-23 00:15:05 +08:00
sshclient -> vps 酸奶 -> sshd
|
Select Language