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
  • 2
  • 7
haunted85
  • 4,201
  • 2
  • 15
  • 9
  • 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?](https://unix.stackexchange.com/questions/36540/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