9

Helo,

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 ?

/etc/ssh/ssh_conf

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 LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Thank you

Edit: I can connect with a password

Preovaleo
  • 99
  • 1
  • 1
  • 3
  • Did you check this Q&A on [serverfault](http://serverfault.com/questions/540004/ssh-access-denied-by-pam-account-configuration-for-one-non-root-user-but-not)? Maybe it is an error in your shadow.conf – Henrik Pingel Nov 10 '15 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 Nov 11 '15 at 21:15
  • any logs in sshd? – neutrinus Nov 16 '15 at 19:43
  • 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 Nov 13 '15 at 09:08
  • What is the exact `ssh` command line? Are you using an agent? If you are using an agent, you can try without agent by prefixing the command with `SSH_AUTH_SOCK=`. – kasperd Nov 18 '15 at 07:34
  • 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 Nov 21 '15 at 10:03
  • Please show the logs from the server. If necessary raise the log level on the server too. – user9517 Nov 23 '15 at 13:47
  • For anyone else who runs across this, the solution is http://superuser.com/q/1016989/93541 – D.W. Dec 23 '15 at 01:24

8 Answers8

3

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.

Community
  • 1
Diamond
  • 8,791
  • 3
  • 22
  • 37
2

Are the privileges on your ssh files correct?

.ssh Folder --> 700

public key --> 644

private key --> 600

Also check user & group

embedded
  • 456
  • 1
  • 6
  • 19
2

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.

Law29
  • 3,507
  • 1
  • 15
  • 28
  • 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 Nov 13 '15 at 09: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 Feb 20 '16 at 20:10
2

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

ostendali
  • 373
  • 1
  • 4
1

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

PubkeyAcceptedKeyTypes=+ssh-dss

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.

jeroen
  • 53
  • 1
  • 2
  • 11
  • this is not the case. There is in question, that the key is RSA. – Jakuje Nov 16 '15 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 Nov 16 '15 at 19:46
  • @jeroen, by default it uses `rsa` key. See fedora ref [here](https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/s2-ssh-configuration-keypairs.html), unless it is customized. Of course one can choose which type of key to configure and use. – Diamond Nov 23 '15 at 18:34
  • My experience was that @Jakuje is correct, though. I found that after upgrading my CLIENT, neither my old DSA key nor a newly-generated RSA key could be used to log in to my (still-F22) server, which normally has password-auth disabled. I had to reactivate it as a workaround. Generating a new ECSDA key (ssh-keygen -t ecdsa) solved the problem, as suggested in this forum thread: http://forums.fedoraforum.org/showthread.php?t=307406 – FeRD Dec 16 '15 at 07:53
  • @FeRD I did try to generate a new RSA key, but I have not tried the ECSDA one. Thanks for the tip, I'll give that a try. – jeroen Dec 16 '15 at 12:06
  • 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 Dec 17 '15 at 02: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 http://superuser.com/q/1016989/93541. – D.W. Dec 23 '15 at 01:25
1

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.

Background

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:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
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.

FeRD
  • 111
  • 4
0

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

NoAngel
  • 311
  • 3
  • 5
0

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.

rubynorails
  • 369
  • 3
  • 14