Description
Christian Heimes
2015-10-22 11:00:07 UTC
Description of problem: Today I upgraded GnuPG 2 to 2.1.9-1.f22. Since the update and a reboot I can no longer use gpg-agent for SSH autentication. Neither my OpenPGP smartcard (YubiKey NEO) nor my file-based keys are working. ssh-add -L also no longer shows any keys, too. A downgrade to 2.1.2 and restart of gpg-agent solved the issue. Version-Release number of selected component (if applicable): broken: gnupg2-2.1.9-1.fc22.x86_64 works: gnupg2-2.1.2-2.fc22.x86_64 How reproducible: Steps to Reproduce: 1. Follow any tutorial like https://inuits.eu/blog/ssh-authentication-your-pgp-key to create an authentication key and use it for SSH 2. run ssh-add -L Actual results: $ ssh-add -L error fetching identities for protocol 1: agent refused operation error fetching identities for protocol 2: invalid format The agent has no identities. Expected results: $ ssh-add -L error fetching identities for protocol 1: agent refused operation ssh-rsa AAAAB3NzaC1... cardno:000603XXXXXX Additional info:
Comment 1
Christine Dodrill
2015-11-10 19:16:27 UTC
I just ran into this today with a slightly different output: ➜ ssh-add -l error fetching identities for protocol 1: agent refused operation 2048 SHA256:PZw/8LniQjqouqoVwPZtlyD7MMwS2xV34MO3DC/tMPk /home/xena/.ssh/id_rsa (RSA) 2048 SHA256:rzU+vEdaHt7giRtkrziQwBwxY/Z+TX/a1ck8cJWcEfk rsa w/o comment (RSA) I did not get the "invalid format" entry for SSH keys, but like you I don't have the PGP smartcard showing up as an SSH key.
Comment 2
Christine Dodrill
2015-11-10 19:30:31 UTC
Downgrading gnupg to the older version (gnupg2-2.1.2-2.fc22.x86_64) fixes this.
Comment 3
Fedora End Of Life
2016-07-19 19:58:08 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
While attempting to connect to some server over SSH, you may get the error as follows:
sign_and_send_pubkey: signing failed for RSA “/home/<username>/.ssh/id_rsa” from agent: agent refused operation
The “agent refused operation” error is usually caused by too open permissions on a private key file.
In this short note i am showing how to fix this error.
Cool Tip: Slow SSH login? Password prompt takes too long? You can easily remove the delay! Read more →
Run ssh-add command on the client machine to add the SSH key to the agent:
$ ssh-add
To force the SSH key to be kept permanently, add it to your ~/.ssh/config file:
Host * IdentityFile /home/<username>/.ssh/id_rsa
If ssh-add causes the message as follows, it means it is required to set more restrictive permissions on the private key file:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0744 for '/home/<username>/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored.
To set the proper permissions, execute:
$ chmod 600 /home/<username>/.ssh/id_rsa
Once the permissions are fixed, the “signing failed: agent refused operation” issue should be solved and you should be able to SSH normally.
Cool Tip: Disable SSH host key checking! Read more →
Configuring SSH Keys from ePass2003 to access servers.
I have a guest ubuntu 16.04 on VirtualBox, i am able to SSH server 1 from VM but while SSH to server 2 from server 1, getting below error.
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV
debug3: sign_and_send_pubkey: RSA SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV
**sign_and_send_pubkey: signing failed: agent refused operation**
When i run ssh-add -l on server 2, i can see the below output.
$ ssh-add -l
error fetching identities for protocol 1: agent refused operation
2048 SHA256:M0HzYuvGQ8LcKpJIGPgQDrN6Xs8jpyjH4wRQdslGeV /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so (RSA)
I have made AllowAgentForwarding yes in /etc/ssh/sshd_config file. But still no luck in getting SSH connection to Server2 from Server1.
If anyone can help me getting through this would be great.
Thanks in Advance !!
For various reasons i would like to use my GPG key for ssh authentication. I’ve configured my system according to http://www.programmierecke.net/howto/gpg-ssh.html with some differences. The steps i’ve taken:
1. DSA key creation. 2048 bits long
2. Instead of creating separate authentication subkey, i’ve used existing one. I’ve selected option 13 of addkey dialog when editing keys with gpg —expert -edit-key USERID. My current keyring is in the following state:
$ gpg --expert --edit-key USERID
gpg (GnuPG) 2.1.3; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub dsa2048/142E5B91
created: 2015-04-12 expires: 2016-09-05 usage: SC
trust: ultimate validity: ultimate
sub elg2048/5AED4D49
created: 2015-04-12 expires: 2016-09-05 usage: E
sub dsa2048/F1FB098D
created: 2015-05-07 expires: 2016-09-30 usage: A
[ultimate] (1). USERID3. I’ve added options to the ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf
$ grep use-agent ~/.gnupg/gpg.conf
use-agent
$ grep enable-ssh-support ~/.gnupg/gpg-agent.conf
enable-ssh-support4. I’ve added keygrip of the key F1FB098D to ~/.gnupg/sshcontrol
$ gpg -K --with-keygrip
/home/mob/.gnupg/pubring.kbx
----------------------------
sec dsa2048/142E5B91 2015-04-12 [expires: 2016-09-05]
Keygrip = 91880564C70B2BC5FB4C83D8A0E0D708498150AB
uid [ultimate] M.Bakhterev <mob@k.imm.uran.ru>
ssb elg2048/5AED4D49 2015-04-12 [expires: 2016-09-05]
Keygrip = 8D356D58565CDBF2912A97AAA5D7B5BFF04BBC8D
ssb dsa2048/F1FB098D 2015-05-07 [expires: 2016-09-30]
Keygrip = 91880564C70B2BC5FB4C83D8A0E0D708498150AB
mob@kite ~/.gnupg
$ grep 91880564C70B2BC5FB4C83D8A0E0D708498150AB ~/.gnupg/sshcontrol
91880564C70B2BC5FB4C83D8A0E0D708498150AB4. Then i’ve started gpg-agent, and checked the SSH environment variables, and that gpg-agent knew the key
$ eval $(gpg-agent --daemon) && (set | grep SSH) && ssh-add -l
SSH_AUTH_SOCK=/home/mob/.gnupg/S.gpg-agent.ssh
_='SSH_AUTH_SOCK;'
error fetching identities for protocol 1: agent refused operation
2048 SHA256:UCWCEQKJH0CpBeFktAqG6DQnORuB1UoA/ef+9U29fk8 (none) (DSA)5. Then, i’ve added public key, as dumped by ssh-add -L to the remote ~/.ssh/authorized-keys file
$ ssh-add -L | ssh REMOTE-LOGIN tee -a .ssh/authorized_keys6. Then i’ve allowed only public key ssh authentication on the remote host and try to login, and get Permission denied (i’ve left only (as i think) relevant part of the whole log)
$ ssh REMOTE-LOGIN -vv
...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: (none)
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 829
debug2: input_userauth_pk_ok: fp SHA256:UCWCEQKJH0CpBeFktAqG6DQnORuB1UoA/ef+9U29fk8
debug1: Trying private key: /home/mob/.ssh/id_rsa
debug1: Trying private key: /home/mob/.ssh/id_dsa
debug1: Trying private key: /home/mob/.ssh/id_ecdsa
debug1: Trying private key: /home/mob/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey)As far as i understand ssh has found the key and offered it to the server. And server has accepted it. But… Something then went wrong. Ok. Here are messages from ssh daemon:
May 07 13:10:24 k sshd[28459]: debug1: Client protocol version 2.0; client software version OpenSSH_6.8
May 07 13:10:24 k sshd[28459]: debug1: match: OpenSSH_6.8 pat OpenSSH* compat 0x04000000
May 07 13:10:24 k sshd[28459]: debug1: Enabling compatibility mode for protocol 2.0
May 07 13:10:24 k sshd[28459]: debug1: Local version string SSH-2.0-OpenSSH_6.8
May 07 13:10:24 k sshd[28459]: debug1: permanently_set_uid: 99/99 [preauth]
May 07 13:10:24 k sshd[28459]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
May 07 13:10:24 k sshd[28459]: debug1: SSH2_MSG_KEXINIT sent [preauth]
May 07 13:10:24 k sshd[28459]: debug1: SSH2_MSG_KEXINIT received [preauth]
May 07 13:10:24 k sshd[28459]: debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com zlib@openssh.com [preauth]
May 07 13:10:24 k sshd[28459]: debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com zlib@openssh.com [preauth]
May 07 13:10:24 k sshd[28459]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
May 07 13:10:24 k sshd[28459]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
May 07 13:10:24 k sshd[28459]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
May 07 13:10:24 k sshd[28459]: debug1: SSH2_MSG_NEWKEYS received [preauth]
May 07 13:10:24 k sshd[28459]: debug1: KEX done [preauth]
May 07 13:10:24 k sshd[28459]: debug1: userauth-request for user maintain service ssh-connection method none [preauth]
May 07 13:10:24 k sshd[28459]: debug1: attempt 0 failures 0 [preauth]
May 07 13:10:24 k sshd[28459]: debug1: PAM: initializing for "USER"
May 07 13:10:24 k sshd[28459]: debug1: PAM: setting PAM_RHOST to "193.104.128.155"
May 07 13:10:24 k sshd[28459]: debug1: PAM: setting PAM_TTY to "ssh"
May 07 13:10:24 k sshd[28459]: debug1: userauth-request for user USER service ssh-connection method publickey [preauth]
May 07 13:10:24 k sshd[28459]: debug1: attempt 1 failures 0 [preauth]
May 07 13:10:24 k sshd[28459]: debug1: test whether pkalg/pkblob are acceptable [preauth]
May 07 13:10:24 k sshd[28459]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
May 07 13:10:24 k sshd[28459]: debug1: trying public key file /USER/.ssh/authorized_keys
May 07 13:10:24 k sshd[28459]: debug1: fd 5 clearing O_NONBLOCK
May 07 13:10:24 k sshd[28459]: debug1: matching key found: file /USER/.ssh/authorized_keys, line 3 DSA SHA256:UCWCEQKJH0CpBeFktAqG6DQnORuB1UoA/ef+9U29fk8
May 07 13:10:24 k sshd[28459]: debug1: restore_uid: 0/0
May 07 13:10:24 k sshd[28459]: Postponed publickey for USER from 193.104.128.155 port 54673 ssh2 [preauth]
May 07 13:10:24 k sshd[28459]: Connection closed by 193.104.128.155 [preauth]
May 07 13:10:24 k sshd[28459]: debug1: do_cleanup [preauth]
May 07 13:10:24 k sshd[28459]: debug1: monitor_read_log: child log fd closed
May 07 13:10:24 k sshd[28459]: debug1: do_cleanup
May 07 13:10:24 k sshd[28459]: debug1: PAM: cleanup
May 07 13:10:24 k sshd[28459]: debug1: Killing privsep child 28460As to my understanding, the key was found and it was successfully matched, but then client has just dropped connection. Why? What is wrong with my setup?
Thanks in advance for any help.
Last edited by c0da (2015-05-09 08:13:37)