2

I am trying to connect to my Ubuntu server using ssh and a public key. I have disabled the connection from remote using a password, so I can only login using a key.

There are two users on my server. When I connect using the pubkey for the first user, everything goes fine. Connection is made, key is checked, I get logged in with no issues.

But when I try to log in as the secondary user, then the connection is refused. These were my steps. Suppose my secondary username is tom.

  1. I created a new pair of keys on my system using ssh-keygen -o -a 100 -t ed25519 -f id_tom -C "tom"
  2. copied the public key into the clipboard
  3. once on the server as tom, I made a new .ssh directory within home and created new authorized_keys file, changing the permissions file to 600 and pasted the public key

  4. I appended the following lines to ~/.ssh/config on my local machine:

    Host tom_server
HostName 687.22.14.4 
User tom
IdentityFile ~/.ssh/path/to/id_tom
IdentitiesOnly yes

Looking at the debug log, I can say that ssh correctly tries to authenticate as tom and the right key is passed to the server. So what could be the issue here? What am I overlooking?

Update: I have tried the solutions posted in Why am I still getting a password prompt with ssh with public key authentication? and nothing so far has worked.

Pang
  • 241
haunted85
  • 4,261
  • did you name the file authorization_keys, or authorized_keys? What are the permissions of ~ and ~/.ssh? – Jeff Schaller Nov 28 '17 at 14:13
  • 2
    Possible duplicate of Why am I still getting a password prompt with ssh with public key authentication? – Jeff Schaller Nov 28 '17 at 14:14
  • @JeffSchaller you are right, I made a typo in the question, which I have edited now. I'm not getting the chance to put in a password, because I disabled it. Permissions for ~ are set to 755 and for .ssh are set to 700. – haunted85 Nov 28 '17 at 14:20
  • Just to clarify (you didn't make it explicit), you created .ssh and authorized_keys on the server, not locally, right? – Jeff Schaller Nov 28 '17 at 14:30
  • @JeffSchaller right! – haunted85 Nov 28 '17 at 14:30
  • The server sshd logs may be helpful; see https://unix.stackexchange.com/a/55481/117549 – Jeff Schaller Nov 28 '17 at 14:32
  • Can you [edit] your question and include these clarifications please? Also clarify that you've checked all of the issues mentioned in the answer to the duplicate post. Finally, does the user who can connect have an authorized_keys2 file by any chance? I admit I don't know why, but I;ve seen some systems use authorized_keys2 instead of authorized_keys. – terdon Nov 28 '17 at 14:32
  • @terdon nope, just authorized_keys. – haunted85 Nov 28 '17 at 14:41
  • In the debug log, what happens when the correct key is tried? Does the server respond with any message or does it drop through to the next authentication mechanism/key? ... do you get debug1: Offering public key tom ... followed by debug2: we sent a publickey packet – RubberStamp Nov 28 '17 at 14:48
  • @RubberStamp when I try to connect with my primary user sshd finds the matching key in authorized_keys and logs me in. And yes if I launch ssh -vvv tom_server I get debug 1: Offering public key... and later debug 2: we sent a publickey packet... – haunted85 Nov 28 '17 at 15:00
  • The prior similar comment had an error... of course, you will want to search the auth log for your connecting ip and not your server ip... sorry about that... So: on the server side... does this give any clues cat /var/log/auth.log |grep "sshd.*your.host.ip.addr" – RubberStamp Nov 28 '17 at 15:50
  • @RubberStamp unfortunately no useful information is listed "received/disconnect/accepted"... – haunted85 Nov 28 '17 at 16:05
  • 1
    Is the content of auth.log the same for the user that works and the user that doesn't work ? ... there should be a bunch of failures in the auth log for the user that doesn't work... these should all have the suffix [preauth] ... unless sshd logging is turned off for some reason... are you running SELinux on your server? ... You question lacks specific details which are necessary to debug your setup. The precise lines of the log files are informative both in complete content and order. >"received/disconnect/accepted" is not helpful. – RubberStamp Nov 28 '17 at 16:45

0 Answers0