ssh passwordless login mostly working, except for a service account to a second box

Question

I had set up a small Linux box a few months ago, and I set up passwordless ssh login for both my personal userid and a service account id. That is working fine for both. I stored the private/public key files for the service account in the same place that I stored the keys for my personal userid, on the client box.

I'm using the following for my basic guide: http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/ .

Today I set up a second box, intending to configure it the same way. I had no trouble getting it to work for my personal userid. However, it's still not working for the service account, but I don't understand why. When I attempt the ssh with the service account to the second box, it prompts me for the password, and then lets me in.

I've verified that the public key for the service account is inserted into the ~/.ssh/authorized_keys file on both boxes, and the key value is the same on both boxes.

I've verified that ~/.ssh has perms of 700, and that ~/.ssh/authorized_keys has perms of 600 (I've also tested with 640, which is what I've read as the recommended value). I've verified this on both boxes, in the home directory for the service account.

Note that the numeric userid for the service account is different on the two boxes. I wouldn't think that would make any difference.

I also note that after I ssh to either box with the service account, if I then try to ssh to the OTHER box from that one, using the service account, it prompts me for a password.

Do I need to do something with "known_hosts", or something else?

Update:

As advised, I tried running ssh with "-v" and inspecting the output from the ssh attempt.

This is the output, with some elisions:

%  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: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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
serviceaccountid@targethost.com's password:

I find it curious that in the last few lines, after "Next authentication method: publickey", the file path references are to "/home/myuserid", not "/home/serviceaccountid". That seems like a big clue.

Answer 1

I can't add comments with my account, but this is just me trying to learn more to help troubleshoot.

It sounds like you have three computers, one local and two remotes. And each of them have two accounts that you're working with?

If you have a personal and service account on the local machine and run ssh service@remote-2 from the personal account on your local machine, then it will only find ssh keys for your local personal account, not the service account.. This shouldn't matter if you've added the local-personal public key to the remote-service account's authorized keys file.

I find it curious that in the last few lines, after "Next authentication method: publickey", the file path references are to "/home/myuserid", not "/home/serviceaccountid". That seems like a big clue.

That's ssh looking for keys in the local account.. It should be the home directory of whatever account you're calling ssh from. If you expect that path to be a service account's home, then you need to log into the service account and then run ssh.