diffie-hellman ssh 密钥交换

发布于 2024-09-03 01:21:45 字数 1194 浏览 5 评论 0原文

我已经开始用 C# 制作一个原始的 SSH 客户端;您可能还记得我在诸如 原始 ssh 连接(低级别) 等帖子中的情况。

不管怎样,在我发起 DH 密钥交换之前一切都很好。 我将建立 ssh 连接(从 openssh 客户端到 openssh 服务器)时的流量与客户端连接到同一 openssh 服务器时的流量进行了比较。

OpenSSH 客户端 -> OpenSSH 服务器(S 表示服务器,C 表示客户端): S:SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r(打招呼) C: SSH-2.0-OpenSSH_5.2\r(自我介绍) C:密钥交换初始化(0x14 = 20) S:密钥交换初始化 C:Diffie-Hellman GEX 请求 (0x22 = 34)(具有 DH GEX 最小值、位数和最大值) S:Diffie-Hellman 密钥交换回复(与 P、G 等) C:Diffie-Hellman GEX 初始化 S:Diffie-Hellman GEX 回复

我的客户 -> OpenSSH 服务器: S:SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r(打招呼) C: SSH-2.0-Some_Name\r(自我介绍) C:密钥交换初始化(0x14 = 20) S:密钥交换初始化 C:Diffie-Hellman GEX 请求(0x22 = 34)(具有 DH GEX 最小值、位数和最大值),

然后是一个伪造的 TCP 数据包作为回复(可能在 GEX 请求之后/之后服务器连接已终止。

我还没有使用 AES128 (我认为这是选择的加密,但我不知道如何验证这一点...),并且我仍然以非压缩格式发送,希望将 P、G 等值获取到 DH 计算。

进行 RFC 4419 第 3 页 http://www.ietf.org/rfc/rfc4419.txt 我已发送 SSH_MSG_KEY_DH_GEX_REQUEST,但服务器未响应 SSH_MSG_KEX_DH_GEX_GROUP。

谁能给我一些我不明白的建议?服务器是否不理解我的 GEX 请求(因为它期望加密,或者?)?

非常感谢任何帮助,谢谢:)

I've set out to make a primitive SSH client in C#; you might remember me from posts such as primitive ssh connection (lowlevel) hehe.

Anyway, things are great up until the time when I initiate a DH key exchange.
I've compared the traffic when I establish a ssh connection (from openssh client to openssh server), to the traffic when my client connects to the same openssh server.

OpenSSH client -> OpenSSH server (S for server, C for client):
S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello)
C: SSH-2.0-OpenSSH_5.2\r (introducing myself)
C: Key Exchange Init (0x14 = 20)
S: Key Exchange Init
C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max)
S: Diffie-Hellman Key Exchange Reply (with P, G, etc.)
C: Diffie-Hellman GEX Init
S: Diffie-Hellman GEX Reply

My client -> OpenSSH server:
S: SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2\r (saying hello)
C: SSH-2.0-Some_Name\r (introducing myself)
C: Key Exchange Init (0x14 = 20)
S: Key Exchange Init
C: Diffie-Hellman GEX Request (0x22 = 34) (with DH GEX min, number of bits and max)

and then a bogus TCP packet as reply (probably the server connection has been terminated after/upon GEX Request.

I have yet to use AES128 (which I think is the encryption chosen, but I'm not sure how to verify this...), and I'm still sending in a non-compressed format, looking to get the P, G etc. values to make the DH calculations.

So where I'm stranded is:
RFC 4419 page 3 http://www.ietf.org/rfc/rfc4419.txt
I've send SSH_MSG_KEY_DH_GEX_REQUEST, but the server does not respond SSH_MSG_KEX_DH_GEX_GROUP.

Can anyone give me a little advice on what I'm not understanding here? Does the server not understand my GEX request (due to it expecting encryption, or?)?

Any help is very much appreciated, thanks :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

决绝 2024-09-10 01:21:46

我很确定问题是在密钥交换初始化之后,密钥没有被(正确)使用。

I'm pretty sure the problem is that after the key exchange init, the keys aren't being taking into (correct) use.

寄意 2024-09-10 01:21:46

我最好的猜测是密钥交换是互斥的,即openssh服务器没有客户端正在寻找的算法客户端没有与openssh服务器交换的算法。您可以通过在 putty 到 openssh 服务器上运行wireshark 来验证它,并监视交换并将其与您自己的客户端进行比较。

我会猜测 putty 是如何工作的,如果交换失败,在“查询 openssh 服务器”以获取它使用的算法后回退到另一个算法...由于 putty 是开源的,因此可能值得您花时间查看查看代码,看看 putty 是如何实现的。

My best guess would be that the key exchange are mutually exclusive, i.e. the openssh server does not have the algorithm that the client is looking for or the client does not have the algorithm to exchange with the openssh server. You could verify it by running wireshark on the putty to openssh server and monitor the exchanges and compare it with your own client.

I would gauge a guess that is how putty works, if the exchange fails, fall back to another algorithm after 'querying the openssh server' for the algorithm it uses... since putty is open source, it might be worth your while to look at the code to see how putty accomplishes it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文