我有一台运行 Linux 6.6.32、OpenSSH_9.7p1 和 OpenSSL 3.0.13(2024 年 1 月 30 日)的服务器。突然,重新启动后,当我从主笔记本电脑登录服务器时,服务器将不再接受我的 ED25519 密钥。在下文中,当我谈论服务器时,我指的是S ;当我谈论笔记本电脑时,我指的是L。
在命令行上从L登录到SPermission denied (publickey,keyboard-interactive)
会产生.如果我(暂时)允许在S上使用密码登录,则会提示我输入密码。
以下是我目前的所有发现:
- L上的默认 SSH 密钥的公钥肯定部署到了S中
/etc/ssh/authorized_keys.d/<username>
- 从L开始,我仍然可以使用相同的 ed25519 密钥 ssh 到具有相同 Linux 和 OpenSSH 版本的各种其他计算机,没有任何问题。
- 从另一台笔记本电脑上,我可以使用该笔记本电脑的默认 ED25519 密钥成功连接到S。
- 如果我在L上创建额外的 SSH 密钥并将相应的公钥部署到S,我可以使用以下命令成功连接:
ssh -i ~/.ssh/test_rsa_key user@S
ssh -i ~/.ssh/test_ed25519_key user@S
- 显式使用L (
ssh -i ~/.ssh/id_ed25519 user@S
)上的默认键不起作用 - 如果我将登录问题的密钥从L添加到S
~/.ssh/authorized_keys
上,它就可以了!但是我为用户提供的其他键如果位于.它也不必对订单做任何事情。/etc/ssh/authorized_keys.d/<username>
从Sjournalctl -u sshd
上我可以看到使用我的默认密钥尝试登录失败会导致:
May 29 16:25:15 S sshd[1836]: Connection closed by authenticating user <user> 81.201.150.231 port 49240 [preauth]
May 29 16:25:33 S sshd[1839]: error: PAM: Authentication failure for <user> from 81.201.150.231
此时,我不能说它是在客户端还是服务器端。我的客户端还使用版本 9.7p1 中的 openssh 包。
这是以下内容/etc/ssh/sshd_config
:
cat /etc/ssh/sshd_config
AuthorizedPrincipalsFile none
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
GatewayPorts no
KbdInteractiveAuthentication yes
KexAlgorithms [email protected],curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256
LogLevel INFO
Macs [email protected],[email protected],[email protected]
PasswordAuthentication no
PermitRootLogin without-password
PrintMotd no
StrictModes yes
UseDns no
UsePAM yes
X11Forwarding no
Banner none
AddressFamily any
Port 22
Subsystem sftp /nix/store/0g1s8yd0biawp32fl3i7kdbi219jx6aq-openssh-9.7p1/libexec/sftp-server
AuthorizedKeysFile %h/.ssh/authorized_keys /etc/ssh/authorized_keys.d/%u
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
我在 ssh、Linux 和 NixOS(我所有机器上的 Linux 发行版)方面拥有多年的经验。但在这种情况下,回滚到较旧的 NixOS 代/版本并没有改变任何内容。非常令人困惑 - 特别是因为只有这个非常有限的情况不再起作用!
相关答案:https://superuser.com/a/1723412
引用:
顺便说一句,您不需要
%h/
在作为参数给出的路径前面AuthorizedKeysFile
,因为相对路径被视为相对于用户的主目录,因此:Alpine Linux v3.19 上的测试似乎证实了给定文件的文件权限很
AuthorizedKeysFile
重要。如果/etc/ssh/authorized_keys.d/username的所有者是username,其中username是认证用户(权限-rw-------
= 600),则认证成功。如果所有者是 root,那么它就会失败(当然,除非以 root 身份进行身份验证并PermitRootLogin
设置为yes
)。从服务器S的角度来看,客户端在身份验证过程中突然关闭了连接。
因此,该错误表明可能存在客户端问题......就服务器而言。
检查任何密钥文件及其所在目录的权限。SSH往往会忽略任何不够安全的密钥文件。
namei -mov $HOME/.ssh/id_ed25519
像(客户端)和(服务器端)这样的命令namei -mov /etc/ssh/authorized_keys.d/username
应该立即显示文件及其所有父目录的权限,这对于检测目录路径上任何位置的不安全目录可能很有用,就像 SSH 一样。但是,如果客户端将其视为服务器关闭连接,则说明中间有某些东西切断了连接。
是否可能在S和L之间存在防火墙或 SSH 代理设备,配置为按内容检测 SSH 连接,并在确定协议是 SSH 或遇到 SSH 协议功能时终止连接不知道如何处理?
(如果似乎存在这种没有正当理由的设备,则可能意味着您的连接正在受到中间人攻击。如果您认为可能是这种情况,并且您是某个组织的成员,有专门的信息安全人员,现在是时候给他们打电话并报告您所看到的情况了。)
我找到了根本原因。 NixOS 24.05 和 openssh 在S和L上都工作得很好。问题是一个不幸的提交,对S的 NixOS 配置文件进行了非常微妙的更改,其中定义了接受的密钥(参考)。
style: fmt and typos
我执行的提交$ typos -w
(参考)将我在L上的用户的公共 SSH 密钥更改为S 的NixOS 配置中的"ssh-ed25519 ***Oen*** user@machine
到
"ssh-ed25519 ***One*** user@machine
这在长字符串的差异视图中并不明显。因此,当应用配置时,NixOS 将现在错误的 SSH 密钥放入S
/etc/ssh/authorized_keys.d/<username>
上。由于我从未完全比较公共 ssh 密钥(实际与预期),而仅比较字符串的开头和结尾,而且 git 历史记录乍一看并不可疑,所以我没想到会出现错误。今天我又看了一遍 git 的历史,是的..这是一个非常微妙的错误。正确的修复方法是从提交中恢复该更改,并
typos
以忽略 SSH 密钥/不尝试在密钥(的子字符串)中查找拼写错误的方式进行配置。感谢大家的意见!