解决 ssh 爆破的一个方法，使用不支持的加密套件

“ ssh 服务器是我手动实现的”

这才是最不安全的方式。

@hingle 用 libssh.org 现有的库实现的，也不能说不安全吧，不然使用 libssh.org 的都不安全了。在 libssh 上层代码，代码也没有超过 100 行，低级错误应该基本都避免了

只允许用证书没有更安全嘛

支持。这个想法很好

证书登录保平安

赞同#1 ，就算用它们的库，你自己的代码会不会有漏洞，你的编译会不会和安全实践不一致，上游的漏洞、补丁是不是及时关注处理，等等

弄一扇正常的防盗门,而不是把门框用水泥糊满

证书登录保平安

ssh 这种服务完全没必要开放给所有 IP

@0o0O0o0O0o 软件已经用上几个月了，就像自己做的东西，在难吃也...，不过现在看起来不是很难吃。

所有人都所有同一个软件，攻击面就会很大。不知道为什么 v 站的风气就是“造不如买”。都觉得使用别人的更安全。

软件只实现了 req-pty ，exec 和 scp [scp 强行把所有文件重定向到 /upload] ，攻击面应该很小。不也有不少人使用 openssh 也不会关注上游的漏洞、补丁啊

反正总要去试的，总比等别人好吧。

希望关注点不要在“ ssh 服务器是我手动实现的”这里

毕竟我喜欢自己手动实现

我使用的 Linux 的组件都被我替换完了。除了 sshd,还编写了一个 dhcp 客户端，替换了 isc-dhcp 。编写了一个 net 管理工具，替换了 systemd-networkd ，什么 NetworkManager ，systemd-resolved 全部被我自己的软件替换了，除了 systemd-udevd 等替换难度巨大的，其他基本都替换了。

我 ss 也是自己实现的，我使用的 ss 移除了 aes 对称加密，使用我自研的对称加密，移除了默认的 hash ，改使用其他的 hash ，还改了默认的认证方式。也没有被封锁过任何 ip 和端口（可能是用的人少，只有我和朋友在用）

希望大家不要过分关注“自己实现是最不安全的方式”这个论点，从某种程度来说，我现在在“以身试毒”。用来验证“自己实现才是最不安全的方式”的论点。什么时候我被黑客日了，我来吱一声

@huahsiung 弄个加密 u 盘，密钥存那里面

@churchmice 感谢你的建议，但是公用电脑我一般是 webssh 或者 novnc 。感觉这个好一点

@huahsiung 虽然动手实践是很好的，但是也要注意 security by obscurity is not security 。

你自编译的虽然抵挡了自动扫描，但是扫描器会把你这个奇葩的握手记下来，说不定哪一天有个友邦黑客大神无聊拿你做“科研”，这时候你没有及时升级 SSH 的其他部分就使你中招了。

另外在不信任电脑上使用私钥的问题可以用智能卡解决，最方便的是 Yubikey ，在大多数电脑上免驱。

感觉楼主这种改客户端的方法不适合大规模部署，对小白也不友好。一般人使用，对于安全还是循序渐进的找到适合自己的最好。

比如：强密码 > 证书登陆 > 改端口 > Fail2ban > 防火墙白名单 > 各种隐藏端口的办法（ vpn or and 端口敲门 or and 加密隧道 等等等等）

@eudemonwind 我只是用我的程序做了给示例,实际上 openssh 也可以很轻松配置自定义加密套件,

配置文件添加 vim /etc/ssh/sshd_config

KexAlgorithms +diffie-hellman-group14-sha512 #指定密钥交换套件

Ciphers [email protected],aes256-ctr #指定加密套件

MACs hmac-sha256 #指定 hmac 算法

差不多就算这样

@billccn 理论跟实践还是有区别的。互联网上大部分扫描攻击都是针对已知漏洞广撒网，对一两个异常不会有兴趣，因为没什么收益。

给哥们的动手精神点个赞
但是我还是想说，自己写的不太可能强过现成的，所以我选择 sshd

#15 说的很对，选择一个小众的加密协议不代表你就安全了，类似于 mac 没病毒这个说法
你没挨打只是因为人家打你不是一片一片的打，不划算，如果有人专心想打你，你这个就可能是纸糊的
正儿八经的 ssh 安全，还是要靠证书验证和限制访问 IP

https://github.com/google/google-authenticator-libpam
两步验证

ip 白名单才是终极安全。哪怕你没有密码都安全得不得了。

@xuanbg #22 要谈安全的话，IP 白名单也不是 100% 安全，如果你其他软件有漏洞，也可能在非白名单 IP 下对你实施攻击。
没有密码都安全得不得了？你最好不要有这种想法。
因为源 IP 是可以伪造的，这个是 DDoS 常用的手段之一，也是 DNS 污染使用的手段之一。但用来单点攻击的话效率太低收益太低，但如果针对性攻击的话，也是存在被利用的可能。
假设你白名单只放行了 2.2.2.2 ，而我在 3.3.3.3 ，我只要伪造一个源地址为 2.2.2.2 的数据包就能过你的防火墙。虽然你的回包会发回给 2.2.2.2 ，我可能收不到，但是如果有其他漏洞的话，一个精心构造的包就可以利用了（甚至于你都没有密码），那实际上也就不关心回包内容了（有可能拿到你主动发过来的反弹 shell ）。
另外，如果攻击者控制了你回包的中间路由链路，比如某地区的出入口链路、或者在你家小区的 ISP ，那么回包的内容也是可以拿到的。

另，我觉得终极安全是让攻击者看不到收益，对你发动攻击的性价比太低，以致于没人愿意攻击你，那才是最安全的。

@jinliming2 源 IP 确实可以伪造，但伪造的 IP 不能建立有效的数据链路啊。所以，伪造源 IP 并不能通过 tcp 协议的 3 次握手，也就谈不上建立 ssh 链接了。

当然，服务的漏洞确实可以利用，但这和 ssh 密码强度并没有关系。要想服务漏洞不影响系统安全，容器化就很轻易地解决了。在容器里的服务，漏洞也就影响这个容器而已。

@jinliming2 #23 请教下 TCP 流量怎么伪造源 ip ，有没有相关资料？

@EricXuu 快进到 2050 年 SSH 登录需要 密码+证书+二验+手机短信+人脸识别+指纹

@xuanbg #24 TCP 三次握手仅仅依赖于 SYN 同步的序号。TCP 序号预测攻击，通过某种方式预测出你服务器响应的序号，然后给服务器发伪造的 ACK 即可。
另外，如我上面所说，如果在骨干网上控制了网络路由的中间节点，比如国际、省级出入口，那么就不需要预测那么麻烦了，直接在中间路由上抓响应包就行。
还有一点是，部分软件会监听 UDP 端口，如果有漏洞的话……

另外，容器化也并非完全安全，容器逃逸也是漏洞挖掘的一个方向，容器内运行的程序逃逸到主机来执行代码。之前刷 CTF 的时候有道题就是在 Linux 下用 wine 虚拟化执行的 Windows 程序，要逃逸到主机执行 Linux 下的程序。

总之，没有绝对的安全，只有提升攻击成本，降低攻击的收益，才能提高安全性。

@Masoud2023 #25 简单了解一下网络数据包的结构，数据包里面包含源地址和目的地址，你只要修改一个数据包里的源地址就行了。

@jinliming2 #27 那您能不能给我讲一下 OSI7 层模型中，IP 工作在哪一层？再在此基础上给我讲一下在 Internet 上伪造 IP 做 tcp 流量的 DDoS 怎么实现？

@Masoud2023 #28 自己动手搜一下，很难吗？又不是啥高深的技术，伸手要的话，给你个关键词 IP address spoofing