我在 Windows（2019）服务器上有一个 PoSh 脚本，我想从 linux 网络服务器上的一个简单的网络应用程序（一个按钮）启动它，所以我启用了 OpenSSH 并将其限制为一个通用的非特权帐户。
在使用用户名/密码身份验证的手动测试中，帐户进行身份验证并且脚本运行良好。
当我建立一个公钥/私钥对时，帐户连接，但脚本失败。失败是当脚本尝试读取必要的 ADSI 查询的（空）结果时。我认为使用密钥对的原因之一是避免将密码硬编码到脚本中。
我唯一能想象的是，基于密钥的身份验证并不是真正的“登录”，并且需要生成某种票证，当安全访问检查需要凭据时，可以将其传递给 AD。我认为在有关在 Windows 上设置/使用 SSH 的所有文档中的某处都会解释这样的警告。
如果我的猜测是真的，解决这个问题的最佳方法是什么？OpenSSH 中是否有一些设置，因此基于密钥的身份验证会生成没有密码的票证？我真的需要将密码放入代码中吗？
谢谢
访问 AD 始终需要凭据。在正常登录中，ADSI（以及 RSAT、SMB 文件共享等）会自动使用 Windows 在登录过程中存储的“默认”凭据——对于 Active Directory，它会从 AD DC获取Kerberos初始票证（如以及为非 AD 集成服务存储您的 NTLM 密码哈希）。您可以运行
klist以查看授予对所有 AD 服务访问权限的“krbtgt/”票证。通常不会，机器不能凭空生成票证——它必须从 AD DC获取票证，为此它需要您的凭据以 AD 可接受的形式。这通常意味着您的密码（或者从技术上讲是您的 PKI 证书，如果为此设置了 AD - 但这不会通过 OpenSSH 工作）。
通过公钥身份验证，服务器上的 OpenSSH 没有任何凭据可用于代表您获取 Kerberos 票证。
一个例外是使用 Kerberos 的“S4U2Proxy”扩展的约束委派，其中系统可以使用自己的“机器”凭据来生成冒充您的票证。但是，这不是 OpenSSH 设置（据我所知，S4U2Proxy 不能用于创建“初始”krbtgt 票证）；一旦将约束委派的权限授予机器，很可能 ADSI 需要要求 Windows 为实际的 LDAP 连接执行此操作。
它可能被认为是通过 WinRM 从 PowerShell Remoting 中“已知”的，只要该功能存在，它就被称为“第二跳问题”。
在提供的选项中，SSH 传输支持不受约束的 Kerberos 委派，但不支持 CredSSP（尽管我不明白为什么文章声称后者更安全——它们都在传输您的凭据，因此两者风险相同）。
这不是 Windows 独有的问题——它也出现在 Unix 站点上，例如运行系统的大学，其中用户有基于 NFS 或 AFS 的主目录，出于同样的原因，无法使用公钥认证。
当然不是——你可以把它放在一个单独的配置文件中。
（其中包含私钥的文件与包含密码的文件之间几乎没有区别......最后它们都是静态的，不会过期的凭据，可以被盗，并且都必须是受到相同程度的保护。密钥对的其他特性使它们值得使用。）
另一种选择是重写您的脚本以在 Linux 上运行，通过 LDAP 访问 Active Directory（例如 python-ldap 或 perl Net::LDAP）。这样，它可以使用 Kerberos 密钥表文件进行身份验证，而不是存储密码——它仍然需要在磁盘上提供相同的保护，但通常具有使用 Kerberos 的优势。