0

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.

  • Do ssh -v and look at the logs. – Rui F Ribeiro Apr 14 '17 at 21:19
0

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.

  • Hopefully you'll now have enough rep to write comments. :) The key part of your answer was "This shouldn't matter if you've added the local-personal public key to the remote-service account's authorized keys file". I still find this a bit confusing, but I appended my personal pub key to the service account's authorized_keys file on the second box, which is also done on the first box, and now it works, so that was the missing element. – David M. Karr Apr 14 '17 at 23:12
  • @DavidM.Karr Awesome, I'm glad I could help. – ctag Apr 14 '17 at 23:16
  • @DavidM.Karr SSH keys can be confusing for sure. I think it helps to keep in mind that they're a single direction link that has to be established between every pair of accounts that you want to use. And the destination account doesn't depend on the local account's name or UID, if you have permission (passwd / key) then you can SSH to that remote account regardless of account name. – ctag Apr 14 '17 at 23:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.