This question already has an answer here:

So I have a few servers set up behind a bastion. I usually hop from bastion -> server A -> server B using agent forwarding. One day I try to log into server B and for no reason apparent to me I gives me: Permission denied (publickey).

After fiddling around trying to get it to work I figure I must have somehow messed up some setting in the ~/.ssh folder on server B, or some other config files. So I go ahead and end up reverting back to a backup of server B.. same thing.

After much googling and frustration I end up reverting back to the last known backup I have of all 3 taken at the same time (it DEFINITELY worked then). After reverting back the bastion, server A and server B I get the same thing! I can get into the bastion, get into A, but I get permission denied when trying to get into B. I'm at a total loss for what could be going on.

Does anyone have ANY idea what could be going on? Any words of advice would be amazing!!

spencer@ip-10-0-1-10:~$ ssh -Av
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/spencer/.ssh/id_rsa type -1
debug1: identity file /home/spencer/.ssh/id_rsa-cert type -1
debug1: identity file /home/spencer/.ssh/id_dsa type -1
debug1: identity file /home/spencer/.ssh/id_dsa-cert type -1
debug1: identity file /home/spencer/.ssh/id_ecdsa type -1
debug1: identity file /home/spencer/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/spencer/.ssh/id_ed25519 type -1
debug1: identity file /home/spencer/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubu                                                                                                                                                             ntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x040                                                                                                                                                             00000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr none
debug1: kex: client->server aes128-ctr none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 65:dc:c0:4f:13:30:60:4d:0d:5e:c9:e2:53:b9:8f:62
debug1: Host '' is known and matches the ECDSA host key.
debug1: Found key in /home/spencer/.ssh/known_hosts:2
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: imported-openssh-key
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/spencer/.ssh/id_rsa
debug1: Trying private key: /home/spencer/.ssh/id_dsa
debug1: Trying private key: /home/spencer/.ssh/id_ecdsa
debug1: Trying private key: /home/spencer/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

marked as duplicate by Stephen Harris, G-Man, Kusalananda, Archemar, Jakuje Jul 18 '16 at 8:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • no no you're missing the point. During the time of the back up the permissions were correct! I know this to be true, that's the mystery! – Spencer Smolen Jul 18 '16 at 1:50
  • It's the restore that matters. If your restore failed to maintain ownerships and permissions then you'll see this problem. You haven't given any details of your backup/restore process. So diagnose it as if it was a normal failure and then if you can't work out why things went wrong raise a question around your backup/restore processes. – Stephen Harris Jul 18 '16 at 1:52
  • I'm using AWS, and I created an AMI (image) out of each server. I just find it really odd that the problem I'm having now with the restored images is the exact same problem that popped up out of nowhere, i.e. the reason I went for a restore in the first place. – Spencer Smolen Jul 18 '16 at 1:59
  • You should post the details we need to see what happened rather than just assume nothing is wrong. Then we can see if you preserved permissions properly or not. For example maybe you did a file copy rather than image copy, and the uid of the files has changed. – Peter Jul 18 '16 at 8:25