3

I'm trying to debug the fact that a new user account cannot successfully SSH into a Centos 7 server using RSA key authentication via the command

ssh theuser@theserver

The following observations can be made:

  • The user account (theuser) exists and is not locked
  • theuser's home folder contains a .ssh directory (700 permission) containing an authorized_keys file (600 permission)
  • the authorized_keys file contains a copy of the public key from the local machine
  • the local machine's ~/.ssh/config file points to the correct key file to use for this server
  • ssh can be successfully achieved by entering theuser's password once the key authentication has failed
  • ssh by public key can be achieved with a different user account
  • the /var/log/secure file does not log anything when the key is refused as theuser

Can anyone suggest any next steps I should take to try and find the source of this problem, as my colleagues and I are stuck?

Edit: included ssh -vvv output

debug1: Host 'theserver' is known and matches the ECDSA host key.
debug1: Found key in /Users/ambulare/.ssh/known_hosts:20
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare (0x7fc#obfuscated#), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

closed as off-topic by Jeff Schaller, terdon Feb 4 '18 at 20:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, terdon
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    What does ssh -vvv theuser@theserver shows? – DevilaN Feb 2 '18 at 10:06
  • What are the permissions of the user's home directory, and of the directory above that? – wurtel Feb 2 '18 at 10:10
  • @wurtel - the home directory has 700 permissions and the directory above that is the /home directory, which has 755 permission and is owned by root – Ambulare Feb 2 '18 at 11:31
  • @DevilaN the output is pretty long, but after all the initial establishing connections and such like, I've added the end of the output to my question. Is there anything that gives a clue there? – Ambulare Feb 2 '18 at 11:40
  • 1
    OK, looks like sth wrong with key not matching. Please try ssh-copy-id theuser@theserver and then try logging again with ssh :) – DevilaN Feb 2 '18 at 12:15
3

Thanks to @DevilaN's suggestion, I have resolved the problem.

Trying ssh-copy-id returned an error "permission denied on authorized_keys". As it was a permissions error, I went back to checking ownership and permissions on the authorized_keys file and despite my setting the ownership to theuser on this file (as in my original question), clearly I or my colleagues had done something since the initial setup that had led to the ownership being changed to "root".

It was a simple ownership problem.

chown theuser:theuser authorized_keys

and voila, ssh is working.

For anyone coming across this answer via a Google search: it seems ownership by the wrong user of the authorized_keys file will cause an ssh login attempt to fail silently without returning or logging anywhere that it is a permissions error - until you do ssh-copy-id.

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