几个月前，我设置了一个小型 Linux 机器，并为我的个人用户 ID 和服务帐户 ID 设置了无密码 ssh 登录。这对双方来说都很好。我将服务帐户的私钥/公钥文件存储在客户端盒子上与我存储个人用户 ID 的密钥相同的位置。
我使用以下内容作为我的基本指南：http://www.howtoing.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/。
今天我设置了第二个盒子，打算以同样的方式配置它。我毫不费力地让它为我的个人用户名工作。但是，它仍然不适用于服务帐户，但我不明白为什么。当我尝试使用服务帐户 ssh 连接到第二个框时，它会提示我输入密码，然后让我进入。
我已验证服务帐户的公钥已插入两个盒子上的 ~/.ssh/authorized_keys 文件中，并且两个盒子上的密钥值相同。
我已经验证 ~/.ssh 的权限为 700，而 ~/.ssh/authorized_keys 的权限为 600（我还使用 640 进行了测试，这是我读到的推荐值）。我已经在服务帐户的主目录中的两个盒子上验证了这一点。
请注意，两个框中服务帐户的数字用户 ID 不同。我认为这不会有任何区别。
我还注意到，在使用服务帐户 ssh 到任一盒子后，如果我尝试使用服务帐户从该盒子 ssh 到另一个盒子，它会提示我输入密码。
我需要对“known_hosts”执行某些操作，还是其他操作？
更新：
按照建议，我尝试使用“-v”运行 ssh 并检查 ssh 尝试的输出。
这是输出，有一些省略：
% ssh -v [email protected]
OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 2: Applying options for *
debug1: Connecting to targethost.com [...] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to targethost.com:22 as 'serviceaccountid'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host 'targethost.com' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuserid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/myuserid/.ssh/id_dsa
debug1: Trying private key: /home/myuserid/.ssh/id_ecdsa
debug1: Trying private key: /home/myuserid/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password:
我觉得奇怪的是，在最后几行中，在“下一个身份验证方法：publickey”之后，文件路径引用是“/home/myuserid”，而不是“/home/serviceaccountid”。这似乎是一个很大的线索。
答案1
我无法使用我的帐户添加评论，但这只是我试图了解更多信息以帮助解决问题。
听起来您有三台计算机，一台本地计算机和两台远程计算机。他们每个人都有两个您正在使用的帐户？
如果您在本地计算机上有个人和服务帐户，并ssh service@remote-2从本地计算机上的个人帐户运行，那么它只会找到您的本地个人帐户的 ssh 密钥，而不是服务帐户。如果您'已将本地个人公钥添加到远程服务帐户的授权密钥文件中。
我觉得奇怪的是，在最后几行中，在“下一个身份验证方法：publickey”之后，文件路径引用是“/home/myuserid”，而不是“/home/serviceaccountid”。这似乎是一个很大的线索。
这就是 ssh 在本地帐户中查找密钥。它应该是您调用 ssh 的任何帐户的主目录。如果您希望该路径是服务帐户的主目录，那么您需要登录服务帐户并然后运行 ssh。