Ssh key accepted by host but client disconnect

First of all, there are numerous, very well written, detailed documentaion on how to setup or configure public key based authentication are available online. Please have a look at one of them and see if you have followed everything correctly. Here is one. So I'm not going to repeat that again.

The very basic concept is (copied from here):

Key-based authentication uses two keys, one "public" key that anyone is allowed to see, and another "private" key that only the owner is allowed to see. To securely communicate using key-based authentication, one needs to create a key pair, securely store the private key on the computer one wants to log in from, and store the public key on the computer one wants to log in to.

Now from the debug log you have posted:

  • It seems there are two different user's are involved. /home/theo/.ssh/authorized_keys and /home/tbouge/.ssh/id_rsa. Are you trying to login as one user to another user's home directory?
  • The error Postponed publickey for theo.. means unwanted authentication method have been tried before publick key method. SSH will try every authetication method that are enabled in config, one after another. In your case you have GSSAPIAuthentication yes enabled what you are not using. You can safely disable it by doing GSSAPIAuthentication no.
  • debug2: we did not send a packet, disable method is most probably that it can't process the private key file (either file permission or name problem). SSH is very sensitive about directory and file permissions in both local and remote computers. (chown user_name:user_group -R /home/user,chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys ). So, make sure yours are set correctly. See this: https://unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server
  • As for the third error: Permission denied (public key)., there are a couple of things to check.

    • Wrong username
    • Wrong key-pair
    • Wrong target host

      • Here are more details: https://stackoverflow.com/questions/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance.

The following part is a little confusing:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

To understand it better, lets go through the authentication process step by step as described here at digitalocean:

  1. The client begins by sending an ID for the key pair it would like to authenticate with to the server.
  2. The server check's the authorized_keys file of the account that the client is attempting to log into for the key ID.
  3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  4. The server sends the client this encrypted message.
  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
  8. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.

In your case, as you can see, the remote computer only accepted your public key, encrypted the packet with that key and sent it back to the client computer. Now the client computer need to prove that it has the right private key. With only the right private_key it can decrypt the recieved message and send an answer back. In this case, the client is failing to do that and the authentication process is ended without success.

I hope this helps you to understand the issues and resolves them.


Are the privileges on your ssh files correct?

.ssh Folder --> 700

public key --> 644

private key --> 600

Also check user & group


You say you have the same key on a windows machine; are you sure that the private key file you have on your Linux machine is correct? Maybe the private key is in a putty format that ssh doesn't understand easily. In any case, if I put an incorrect or invalid private key file, I get exactly the same error that you have.

To correct the problem, it would be more proper to generate a new key on the Linux machine instead of reusing a key from another machine. You can just add the new public key to the authorized_keys file on the host, and then you can use both the Windows key from Windows and the new Linux key from the Fedora.


your problem seems to be pretty common and also clear I have say.

 Permission denied (publickey).

does that means anything to you? to me it means a lot to me.

can you check on server side if you have selinux runnin in enforced mode pls? if not tell me what mode is selinux running to.

Also, if you can do one more attempt and capture the audit logs of that attempt and post here it will definitely tell us why:

  tail -f /var/log/audit/audit.log  (and try to attempt)

It is permission problem that is clear but not file permission:-)