6

Running xubuntu 16.04, with xfce, I'm trying to use ssh keys with passphrases. I would like to add my passphrased key to my ssh-agent, but I don't know why I can't add it. I don't have gnome keyring enabled or anything alike in my startup. ssh-add privatekey, adds the key but when I try to ssh again it just prints the error two times. Some fixes say to disable the gnome keyring on startup but I've already had it disabled. This all occured when I replaced the ssh keys for my raspberrypi.

enter image description here

> OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016 debug1: Reading configuration data /home/potato/.ssh/config debug1: /home/potato/.ssh/config line 1: Applying options for paj debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 111.229.105 [111.229.105] port 22253. debug1: Connection established. debug1: identity file /home/potato/.ssh/hplaptop_to_pi type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/potato/.ssh/hplaptop_to_pi-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u3 debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u3 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 111.229.105:22253 as 'pi' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:zrjeaaHD8TjzsdsdssssA2fXnG3gxp2U debug1: Host '[111.229.105]:22253' is known and matches the ECDSA host key. debug1: Found key in /home/potato/.ssh/known_hosts:2 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: rekey after 134217728 blocks 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: /home/potato/.ssh/hplaptop_to_pi debug1: Server accepts key: pkalg ssh-rsa blen 535 sign_and_send_pubkey: signing failed: agent refused operation debug1: Offering RSA public key: potato@potato-HP-tomato debug1: Authentications that can continue: publickey debug1: Offering RSA public key: potato@hplaptop debug1: Authentications that can continue: publickey debug1: Offering RSA public key: potato@hplaptop debug1: Server accepts key: pkalg ssh-rsa blen 535 sign_and_send_pubkey: signing failed: agent refused operation debug1: Offering RSA public key: rsa-key-20141222 debug1: Authentications that can continue: publickey debug1: Offering RSA public key: potato@potatolaptop debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey).
Improve this question
4
  • What is the result of ssh-add -L? What is in echo $SSH_AUTH_SOCK? Commented Mar 12, 2017 at 10:21
  • ssh-add -L outputs the public(private?) keys, a few of them. echo #SSH_AUTH_SOCK outputs /run/user/1000/keyring/ssh Commented Mar 12, 2017 at 10:32
  • Obviously public keys. This says that you are using gnome-keyring or something else then ssh-agent. Commented Mar 12, 2017 at 10:34
  • Wierd, and im not sure what could it be. I dont recall installing anything else that would manage my keys. Commented Mar 12, 2017 at 10:36

3 Answers 3

Reset to default
10

So after hours of mindless googling and help, the problem was uncovered. I was generating my ssh keys with ssh-keygen and added an additional argument "-o" which generated the keys in a new format for openSSH. The problem was that my gnome-keyring did not support such keys as the keys had Ed255519 signature scheme. Gnome-keyring does not support that since 3.20. I reverted to RSA and no more problems!.

Improve this answer
2
  • 2
    You can also use a keyring which support Ed25519, such as Keychain. Commented Dec 5, 2017 at 8:19
  • Yes, but I think then I wanted to use the ssh-agent, which asks you for the passphrase then inside the shell, instead of the GUI keyring from xubuntu. Commented Dec 7, 2017 at 15:41
4

In my case the problem was that GNOME keyring was holding an invalid passphrase for the ssh key to be used. After spending indecent amount of time troubleshooting this issue I ran seahorse and found the entry to hold empty string.

I can only guess that it was caused by mistyping the passphrase at first use some time earlier, and then probably cancelling the requester or so in order to fall back to command line.

  • Updating the entry with correct passphrase immediately solved the problem.

  • Deleting that entry (from "login" keyring) and reentering passphrase at that first prompt (and checking the appropriate checkbox) solves this too.

Now agent gets the correct passphrase from the unlocked at login keyring named "login" and neither asks for passphrase nor "refuses operation" anymore. Of course YMMV.

Improve this answer
1
  • 1
    Gah! What a terrible UX. I am so glad I found your post here, otherwise I probably would have thrown up my hands and reinstalled this blighted machine. Now it works! Thanks! Commented Sep 20, 2021 at 22:18
1

A lot of suggestions to resolve such an issue hint at changing permissions of the ~/.ssh directory and the files it contains. More on this : https://gist.github.com/grenade/6318301

Some even suggest ssh-add which may not solve the issue and might be redundant.

Having tried both of the above, did not solve this problem for me. Instead, the problem was with the type of ssh key I was generating.

As @strudelj nudelj mentioned, it is important to check if the encryption type used by your public key is supported by the server you are connecting to. For example, a gitlab server I was trying to did not support the type of keys usually stored in ~/.ssh/id_dsa.pub

Instead, it required ed25519 or rsa encrypted keys.

For ed25519, one can use: $ssh-keygen -t ed25519 -C "[email protected]" to generate the key

Then, $ssh -T user@server should offer a good check if this key is accepted and a connection can be established.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.