I have a problem with SSH after fedora 23 installation.

When i wan't to connect to my remote host with private key my host find the key :

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

But as you see my client disconnect by it self

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
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
debug1: No more authentication methods to try.
Permission denied (publickey).

I can connect to my host with putty on windows using the same private key and i can connect with my phone using a different private key.

Do you have any idea ?


Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv XMODIFIERS

Thank you

Edit: I can connect with a password

  • Did you check this Q&A on serverfault? Maybe it is an error in your shadow.conf Commented Nov 10, 2015 at 22:53
  • do you see any SELinux denials or SECCOMP messages in audit? ausearch -m SECCOMP or ausearch -m AVC? There were some changes recently that could affect some setups.
    – Jakuje
    Commented Nov 11, 2015 at 21:15
  • 1
    Helo, Thank you for all your answers but i didn't find what happened. I downgrade to f22 and now it works. have a nice day
    – Preovaleo
    Commented Nov 13, 2015 at 9:08
  • any logs in sshd?
    – neutrinus
    Commented Nov 16, 2015 at 19:43
  • 1
    The main thing that is missing here is the logs from the server. The client logs can never tell the whole story. If you add the relevant server logs, the chance of getting an answer will rise significantly.
    – Jenny D
    Commented Nov 21, 2015 at 10:03

8 Answers 8


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.

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

  • Thank you for your answer but i already check that.
    – Preovaleo
    Commented Nov 10, 2015 at 15:53

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.

  • Thank you for your answer but yes the private key is good(fun fact : 1 hour to find how to use it in putty!!).
    – Preovaleo
    Commented Nov 13, 2015 at 9:06
  • According to your (very well-reasoned) resolution of the problem, the private key was good, but the client couldn't use it even though it thought it should be able to. I suspect there might have been something that was supposed to ask you for your passphrase but failed to do so. That would explain why it worked before the upgrade; the upgrade either set up the ask-for-a-passphrase procedure wrongly or messed it up if it was already there, and sudo authconfig --updateall fixed it.
    – Law29
    Commented Feb 20, 2016 at 20:10

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:-)

  • +1 Seen it on RHEL7.1 setups as well. Please expand with audit2allow :)
    – kubanczyk
    Commented Nov 21, 2015 at 9:43

It seems the problem (in my case...) was caused by the type of key.

I have just now solved it adding the following to the local ~/.ssh/config file (the Fedora 23 client machine):


Although I have added that line to both the server and the client config file, only the client side made the difference. Note that the permissions need to be 600 for the config file to be read.

  • this is not the case. There is in question, that the key is RSA.
    – Jakuje
    Commented Nov 16, 2015 at 19:42
  • @Jakuje Yes, it would seem so, I hadn't noticed. Well, maybe it helps other people as I had the exact same problem after upgrading yesterday.
    – jeroen
    Commented Nov 16, 2015 at 19:46
  • @jeroen, by default it uses rsa key. See fedora ref here, unless it is customized. Of course one can choose which type of key to configure and use.
    – Diamond
    Commented Nov 23, 2015 at 18:34
  • 2
    @jeroen In further testing I don't recommend it; gnome-keyring-daemon doesn't pick up $HOME/.ssh/id_ecdsa files, unfortunately, so those keys won't be unlocked and added to the session's ssh-agent automatically on login. Anyway, I've since upgraded my server to F23, and there are no problems going between it and the remaining F22 client (in either direction) using RSA keys. While the ECSDA key does provide a workaround for my one laptop that needs it (where any attempts to use RSA keys fail), the root problem appears to be something else.
    – FeRD
    Commented Dec 17, 2015 at 2:56
  • 1
    Thanks for the helpful answer. Note that you'll need to make the same change on the server, if the server is upgraded to OpenSSH 7.0 or newer (e.g., if it is upgraded to Fedora 23 or higher). See superuser.com/q/1016989/93541.
    – D.W.
    Commented Dec 23, 2015 at 1:25

I don't know if anyone else is still having this problem, but I finally solved it for my one machine (a laptop) that was experiencing the issue. I believe I know what eventually sorted it out, and I'll leave the info here in the hopes that it will help anyone else who might still be encountering this — and also so that someone can hopefully check my solution and confirm that it's actually what solved the problem.

The issue, as it turns out, wasn't (for me) with SSH at all, but with how PAM was configuring my keys. The configuration in /etc/pam.d was out of date (though it was working properly through Fedora 22), and as a result the correct things weren't being done on login [anymore] to pick up my keys from $HOME/.ssh/. Running this command:

# sudo authconfig --updateall

rebuilt the /etc/pam.d configuration properly. On next reboot, after I logged in, the first time I tried to ssh out to my server, a dialog box asked me to enter my passphrase for my ssh key ($HOME/.ssh/id_rsa). I did so, checked the "Automatically unlock on login" box, and voila! My ability to ssh out from the laptop was restored.


The clue that led me to solving this came when I imported an RSA key from an external source. (A USB key I carry around, with my "remote access" key for my home network. I turned off PasswordAuth to my outward-facing server years ago after an intrusion.) After ssh-add-ing THAT RSA key, unlike the one sitting in $HOME/.ssh/id_rsa, it was accepted by the remote server without problem.

Then I ended up doing what should've been a redundant ssh-add, to pick up $HOME/.ssh/id_rsa. I noticed that after I'd done that, ssh-add -l contained two entries for the same key:

% ssh-add -l
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Notice how one of the two entries doesn't show the key identifier, just the private key filename matching its public signature. As though the private key wasn't really unlocked by the keyring manager.

I believe that's exactly what was happening, and PAM was passing "bad keys" to the SSH agent that hadn't been unlocked with the passphrase. So, when ssh attempted to authenticate with the key, it didn't actually have the (unlocked) private half of the key pair, and so authentication failed.

That last bit is conjecture, but regardless if anyone is having problems with ssh keys not being accepted by remote hosts (where they used to be) after upgrading to F23, rebuilding the /etc/pam.d/ directory using authconfig is worth trying as a solution.


Check user home directory permissions. It's important. Must be 755. 700 or 770 will not work.


In your ssh_config, try uncommenting and/or adding/removing/appending to either the Cipher, Ciphers, or MACs line(s).

It appears to me that sshd is looking for a particular cipher of some sort that is not being included in the request, which can be added by configuring it in your ssh_config.

...and I'm assuming you don't by any chance have PubkeyAuthentication set to no on the remote server, because that would definitely cause this to fail.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .