看起来你遇到的问题是带verify-required属性的ED25519-SK密钥在第一次连接后被自动加入ssh-agent，但后续连接时agent拒绝签名操作，且没有触发PIN/触摸验证。结合你的环境和操作步骤，我来帮你拆解可能的原因和排查方向：

核心原因推测 #

你的密钥生成时指定了-O verify-required，这要求每次使用该密钥签名时都必须完成验证（PIN+触摸）。但第一次连接时ssh自动将密钥加入agent的过程中，可能没有正确把这个强制验证的属性传递给agent，导致后续agent尝试跳过验证直接签名，被密钥的安全策略拒绝，从而抛出agent refused operation错误。

具体排查与解决步骤 #

1. 确认密钥的verify-required属性是否生效

先检查本地密钥的属性，确保生成时的配置正确：

ssh-keygen -L -f ~/.ssh/servers_ed25519_sk

输出中应该包含verify-required字样，确认密钥本身确实要求每次验证。

2. 重新手动添加密钥到ssh-agent，明确验证要求

先从agent中移除现有密钥：

ssh-add -d ~/.ssh/servers_ed25519_sk

然后手动添加密钥，同时显式指定验证策略（虽然密钥本身已经带这个属性，但手动添加可以确保agent正确识别）：

ssh-add -t verify-required ~/.ssh/servers_ed25519_sk

添加时会提示你输入PIN和触摸密钥，完成后再次尝试ssh连接，看是否会触发验证请求并正常连接。

3. 检查ssh-agent的启动与环境变量配置

你使用ssh-agent -c在fish shell中启动agent，而-c参数生成的是csh/tcsh风格的环境变量设置，fish需要转换格式才能正确识别。如果环境变量没正确设置，可能导致agent与ssh客户端的通信异常，影响验证触发：

• 先关闭当前agent：ssh-agent -k
• 重新用fish兼容的方式启动：

eval (ssh-agent -c | sed 's/setenv /set -x /g')

然后重新添加密钥并测试连接。

4. 调整ssh客户端的AddKeysToAgent配置

默认情况下AddKeysToAgent yes会自动将密钥加入agent，但可能没有传递验证属性。你可以修改~/.ssh/config或者在命令中添加参数，改为confirm模式：

ssh vagrant@127.0.0.1 -p22150 -i ~/.ssh/servers_ed25519_sk -vvv -o IdentitiesOnly=yes -o AddKeysToAgent=confirm

这种模式下，ssh会在添加密钥到agent前询问你，确保验证属性被正确传递。

5. 排除服务器端问题（你已经初步确认，但可以再验证）

既然第一次连接成功，服务器端的openssh-server版本（8.4p1）支持ED25519-SK密钥，所以问题大概率在客户端agent的处理上。如果上述步骤无效，可以尝试在不使用agent的情况下连接（临时禁用agent）：

ssh vagrant@127.0.0.1 -p22150 -i ~/.ssh/servers_ed25519_sk -vvv -o IdentitiesOnly=yes -o IdentitiesAgent=no

如果这次能正常触发PIN/触摸验证并连接，就完全确认是agent的配置问题。

备注：内容来源于stack exchange，提问作者func0der