Erlang、SSH 和authorized_keys

发布于 2024-08-24 18:30:37 字数 610 浏览 5 评论 0原文

在使用 Erlang 中的 sshpublic_key 应用程序时,我发现了一个很好的功能

我尝试使用 rsa 密钥 连接到正在运行的 Erlang SSH 守护进程,但身份验证失败,系统提示我输入密码。

经过一些调试和跟踪(以及几杯咖啡)后,我意识到,由于某种奇怪的原因,我的用户存在一个无效的密钥。 authorized_keys 文件包含两个密钥。错误的位置位于文件中的某个位置,而正确的位置则附加在文件末尾。

现在,Erlang SSH 应用程序在将提供的密钥与authorized_keys 中包含的密钥进行比较时,它找到第一个条目(完全忽略第二个条目 - 正确的条目)。然后,它切换到不同的身份验证机制(首先它尝试dsa而不是rsa,然后提示输入密码)。

问题是:此行为是有意为之还是 SSH 服务器应该在 authorized_keys 文件中检查同一用户的多个条目?这是通用的 SSH 行为还是仅特定于 Erlang 实现?

Playing with the ssh and public_key application in Erlang, I've discovered a nice feature.

I was trying to connect to my running Erlang SSH daemon by using a rsa key, but the authentication was failing and I was prompted for a password.

After some debugging and tracing (and a couple of coffees), I've realized that, for some weird reason, a non valid key for my user was there. The authorized_keys file contained two keys. The wrong one was at some point in the file, while the correct one was appended at the end of the file.

Now, the Erlang SSH application, when diffing the provided key with the ones contained in the authorized_keys, it was finding the first entry (completely ignoring the second on - the correct one). Then, it was switching to different authentication mechanism (at first it was trying dsa instead of rsa and then it was prompting for a password).

The question is: Is this behavior intended or should the SSH server check for multiple entries for the same user in the authorized_keys file? Is this a generic SSH behaviour or it's just specific to the Erlang implementation?

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

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

发布评论

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

评论(1

彩扇题诗 2024-08-31 18:30:37

是的,这是“第一次失败”身份验证,我多次遇到过您的问题。就实现而言,有人向我解释说,该恶魔会迭代authorized_keys 文件以查找匹配的登录名,然后检查密钥。

这似乎是标准实现,

Yes, its a 'first failure' authentication, and I came across your issue several times. As far as implementation goes, it was explained to me that the demon iterated over the authorised_keys file looking for a matching login, and THEN checked the key.

This seems to be the standard implementation,

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