RT 更改了默认的 22 端口，几天观察下来，尝试登录的记录一点都没有减少。
作为一项安全访问措施， [更改 ssh 默认的 22 端口] 可以移除了。

咋？观察一下一台机器就能得出结论。

设置 ssh 为只允许 pub key 登录，你就会发现没人再去尝试登录你的机器了

优先扫[1-9]022,[1-9]021,相信你是正常人,话说全扫一下也花不了多少时间

好的工具 1-65535 端口探测只需要十几秒钟

用 nmap 扫一遍 tcp 端口花不了多生时间，换端口增加安全性只适用于 udp ，因为那个不会应答吧

ssh 的特征非常明显，用 telnet 敲下端口就返回协议类型了，扫全端口也花不了多长时间。

你就不能换成 ssh key 登录吗...

没有那么绝对，我国内腾讯云的机器设置了只允许 Pubkey 登录，也禁止了密码登录，lastb 能看到每天还是有很多乱七八糟的用户名尝试登录。

fail2ban

我这是任意抽检两台云服务器观察一周得出的这个结论，可靠性应该是很高的。
密钥登录和密码登录的安全性，现在还有争论。
确实低估了扫描工具的威力，我故意选用的高位端口，仍旧避免不了被扫。

我是服务商防火墙配置一次规则、服务器本身防火墙配置一次规则，如果要在服务器开放一些 HTTP 管理界面的话，用 Cloudflare tunnel + mTLS 双向证书，安全性无敌。

端口扫描又不是什么高深的东西，咱 20 年前初中就在玩的东西了，称不上什么威力，这种广泛使用的协议太明显了。

私钥登录

有一点，但不多。

爱扫就扫呗，我服务器还关了 ping ，直接装死

ssh 协议是服务器主动的协议
这种协议随便一扫就知道端口号是多少了
更改端口号真的没什么意义

放个陷阱端口啊，低位端口放一个陷阱，只要这个端口有 tcp 扫立刻 ban ip……轮不到高位暴露

放陷阱端口的意义在于，除了骇客在扫，网安也在扫你，云服务商的各种外包云安全也在扫你，不想接受他们“插一杠子”式的服务的话，做个微型蜜罐有益无害

所以我选择 VPN 连接，用 VPN 内网地址去登录云服务器。为了给 VPN 备份，主机开放 22 端口，但云服务器的安全组规则会直接封掉 22 端口，一旦 VPN 失效，去控制台临时放行一下 22 端口依然可以正常访问，不会被关在门外。

确实，主要还是禁止密码登录，设置只能密钥登录

只有一丁点作用，能减少一部分傻瓜的扫描器，降低服务器负载，降低网络开销
还是推荐改一下

fail2ban ，指数增长地增加拉黑时间

＃17 这种有啥开源工具能做到这效果不

好方法

pubkey 登录，fail2ban

我是直接用阿里云的安全组，ssh 还是保持为 22 ，平时直接阻止所有 ssh 连接，需要连的时候， 就手动把当前自己的外网 IP 加入白名单允许一下 ssh 连接，用完再关。

改端口是最没用的，

fail2ban 能阻止频繁重试，但如果对方 IP 多也能不断换

knockd 端口敲门，默认不开启 22 端口，只有先用暗号敲门，比如 3089 9981 2416 三个端口依次连接过后，再对这个 IP 地址单独放行，不知道暗号扫描也扫不了

我发现爆破的都是境外 IP 地址，白名单只允许大陆 IP 就行了

改端口的功能不是给防攻击用的 而是让用户可以把 22 端口给别的程序用

应用场景举例：
（一）某个“智商极高”的程序员的 HTTP 服务器在代码里面写死了监听 22 端口
（二）在 22 端口上开启 netcat 或者其他程序，检测其他 ssh 客户端发过来的握手包具体内容

拿证书登录不就一劳永逸了?

knockd 这玩意要有对应的 ssh 客户端配合用，就很给力。不然连接之前还得写个 for 循环先探测一下😂

想不让扫是不可能的，直接禁密码就行了，别的可有可无。

自带的就很好用 knock myserver.example.com 123:tcp 456:udp 789:tcp

云服务商其实都有 API 给你远程操控防火墙，我自己的服务器只对外开 443 端口，22 端口要走白名单，这个白名单里有一条是我的 IP ，cron 脚本定期更新。

推荐一个 go 项目 github.com/yosebyte/passport ，用他带认证的转发模式，不在 ip 白名单的直接丢包

＃3 要是我用 x3389 阁下又该如何应对

＃10

密钥登录和密码登录的安全性，现在还有争论。

OP 你无敌了，真的

只允许 key 登陆不是常规操作吗？
扫 端口的遇到要求 key 登陆的错误提示就不会再扫你的 ip 了

改端口确实没有任何意义，现在 cpu 和网络已经足够快了，全端口扫描也只是 10 秒的事。
我想了想，唯一改端口的收益是在于避免 GFW 的干扰上。

我的看法是 fail2ban 能解决改端口解决的所有问题，还更优雅，我已经至少五年没用过 22 以外的端口 ssh 了。

唯一不能解决的是 gfw 封端口的问题，但我印象里以前开新机，22 端口经常被阻断连不上，一配置好 fail2ban 立马好了，不像是 gfw 的问题，我不清楚原因是什么，可能是太多人尝试爆破把连接数占满了（或者类似原因）？

确实没大用，但也不是完全没用。

我曾经也是密码+高位端口，很多机子都可以避免被大量扫爆，但也遇到过被人盯着高位端口爆破了几万次。

改成证书登录吧，还有没有人继续扫爆我不知道，但起码 lastb 里不会再有记录了，看着安心点。 ^^_

甚至不需要任何第三方工具，单凭 nftables 就能实现

tcp dport 22 ip saddr add { ip saddr timeout 1d }
tcp dport 22 ip6 saddr add { ip6 saddr timeout 1d }
ip saddr counter drop
ip6 saddr counter drop

同理，nftables 也能直接实现端口敲门，不需要任何额外软件

顺便我自己安全性要求高的直接 SSH Certificate 登录

set 的名字不小心打错了，然后复制粘贴就全错了

另外 nftables 需要先预定义这个 set

set honeypot_ipv4 {
type ipv4_addr
flags dynamic,timeout
timeout 1d
elements = { }
}

大门装锁对安全防护一点作用都没有，几天观察下来，还是会被撬开。以后大门可以不用装锁了

key 登录 和 密码登录 安全性 有争论？？ 哈？

以前个人站，在 web 设置一个深度隐藏 url 地址，打开后需要验证，定期通过 cron 脚本提取源 IP 加入到 ssh 白名单和放开防火墙。

< 我的 22 端口直接是 Gitea 的 ssh server, xswl 看他怎么破

密钥登录+IP 白名单

一般防火墙自定义攻击类型能做到，但是如果你的服务器特别招恨的话（比如ＭＣ服），建议发个 SYN+ACK 回去，对方 ACK 了再 BAN ，因为 IP 来源可以造假。

在我的 VPS 上效果很明显，之前一直有被枚举，换了端口就绝迹了。

密钥有什么办法保存呢，在客户那登录的话？

改 22 默认端口，扫描记录真的少很多

话说有没有可能做个蜜罐，然后在对面连蜜罐 SSH 端口的时候产生大量无用日志或者让对方主动下载文件之类的把对面撑死？

＃17 在 22 端口放了个蜜罐，结果被安全部门找到了

这本身也不是光靠改端口能解决的事啊。