-1

I was running an Ubuntu 14.04 server with SSH enabled and password login turned off. I accidentally fubared the permissions to my ~/.ssh directory, effectively locking me out.

I managed to use a LiveUSB to mount the drive and enable password login and fix the permissions, but now it always prompts for a password, even after I installed an updated SSH key. Why is it doing this and how do I prevent it? I don't want to try turning off password login for fear of locking myself out again.

I tried running ssh -i mykey.pem -vvv user@remote_server.com, and get the output:

debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:cAx828kYj3SWm8lMubqqvq1w9xLh9lxUN/vpCZ7gdk
debug3: hostkeys_foreach: reading file "/home/chris/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/chris/.ssh/known_hosts:375
debug3: load_hostkeys: loaded 1 keys from remote_server.com
debug3: hostkeys_foreach: reading file "/home/chris/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/chris/.ssh/known_hosts:376
debug3: load_hostkeys: loaded 1 keys from 75.101.158.254
debug1: Host 'remote_server.com' is known and matches the ECDSA host key.
debug1: Found key in /home/chris/.ssh/known_hosts:375
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
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: chris@localhost (0x557a0dc45410), agent
debug2: key: roles/qa/qa-ubuntu.pem ((nil)), explicit
debug3: send packet: type 5
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,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,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: chris@localhost
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,password
debug1: Trying private key: roles/qa/qa-ubuntu.pem
debug3: sign_and_send_pubkey: RSA SHA256:Np4f4uwDmx/HgP7m2mIc1pZWeHlrmjreuj2cuLybRhg
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,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

However, most of this doesn't make sense to me. I don't see any explicit error message as to why it's rejecting my key. Why is it still requiring a password?

Cerin
  • 3,497
  • 17
  • 57
  • 72

2 Answers2

1

Check that the parent directory containing your private key (in this case, roles/qa) has 0750 permissions.

On server side, check if something is logged inside /var/log/auth.log and /var/log/secure

shodanshok
  • 44,038
  • 6
  • 98
  • 162
0

I don't see any explicit error message as to why it's rejecting my key. Why is it still requiring a password?

You don't. The reason is logged in the server log. You don't want to provide potential attacker any more information than needed (key is rejected). And since both you and server still have allowed password authentication, there is no error and you are prompted for a password. You can prevent this behavior by setting PasswordAuthentication=no in your ssh_config. It will make your connection fail immediately after the key is rejected (if you want). Or just

ssh -i mykey.pem -oPasswordAuthentication=no user@remote_server.com
Jakuje
  • 9,145
  • 2
  • 40
  • 44