SSH вход без пароля в основном работает, за исключением служебной учетной записи для второго ящика

Несколько месяцев назад я установил небольшой Linux-сервер и установил беспарольный вход по ssh как для своего личного идентификатора пользователя, так и для идентификатора учетной записи службы. Это отлично работает для обоих. Я сохранил файлы закрытого / открытого ключей для учетной записи службы в том же месте, где я хранил ключи для своего личного идентификатора пользователя, в ящике клиента.

В качестве основного руководства я использую следующее: http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/ .

Сегодня я установил второй ящик, намереваясь настроить его таким же образом. У меня не было проблем с тем, чтобы заставить его работать на моем личном идентификаторе пользователя. Однако он по-прежнему не работает для учетной записи службы, но я не понимаю, почему. Когда я пытаюсь использовать ssh с учетной записью службы во втором поле, он запрашивает у меня пароль, а затем позволяет войти.

Я проверил, что открытый ключ для учетной записи службы вставлен в ~ / .ssh / authorized_keys на обоих полях, и значение ключа одинаково в обоих полях.

Я проверил, что ~ / .ssh имеет perms 700, а ~ / .ssh / authorized_keys имеет perms 600 (я также тестировал 640, это то, что я прочитал как рекомендуемое значение) . Я проверил это на обоих полях в домашнем каталоге учетной записи службы.

Обратите внимание, что числовой идентификатор пользователя для учетной записи службы отличается в двух полях. Я бы не подумал, что это будет иметь значение.

Я также отмечаю, что после того, как я подключусь по ssh к любому из ящиков с учетной записью службы, если я затем попытаюсь подключиться к ДРУГУЮ ящик с этим, используя учетную запись службы, мне будет предложено ввести пароль.

Нужно ли мне что-то делать с «known_hosts» или что-то еще?

Обновление :

Как было рекомендовано, я попытался запустить ssh с «-v» и проверить результат попытки ssh.

Это результат с некоторыми исключениями:

%  ssh -v serviceaccountid@targethost.com
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: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  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
serviceaccountid@targethost.com's password:

Мне показалось любопытным, что в последних нескольких строках после «Следующий метод проверки подлинности: publickey» ссылки на пути к файлам указывают на «/ home / myuserid», а не на « / главная / serviceaccountid ". Это похоже на большую подсказку.