¿Cómo resolver "sign_and_send_pubkey: la firma falló: el agente rechazó la operación"?

Configuración de una nueva gota de océano digital con claves SSH. Cuando ejecuto ssh-copy-idesto es lo que obtengo:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

Sin embargo, cuando intento entrar por SSH, sucede esto:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Al ingresar la contraseña, inicié sesión sin problemas, pero esto, por supuesto, frustra el propósito de crear la clave SSH en primer lugar. Decidí echar un vistazo al lado del servidor ssh-agent y esto es lo que obtengo:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

user / .ssh / authorized_keys contiene una entrada de clave ssh-rsa, pero find -name "keynamehere"no devuelve nada.

Ejecutar ssh-adden la máquina cliente, que agregará la clave SSH al agente.

Confirme con ssh-add -l(nuevamente en el cliente) que efectivamente se agregó.

Después de actualizar Fedora 26 a 28, enfrenté el mismo problema. Y faltaban los siguientes registros

/var/log/secure
/var/log/messages

PROBLEMA:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

El mensaje de error no indica el problema real. Problema resuelto por

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

Estaba teniendo el mismo problema en Linux Ubuntu 18 . Después de la actualización de Ubuntu 17.10 , cada comando de git mostraría ese mensaje.

La forma de resolverlo es asegurarse de tener el permiso correcto en id_rsay id_rsa.pub.

Verifique el número de chmod actual usando stat --format '%a' <file>. Debería ser 600 para id_rsa y 644 para id_rsa.pub.

Para cambiar el permiso sobre los archivos, use

chmod 600 id_rsa
chmod 644 id_rsa.pub

Eso resolvió mi problema con la actualización.

Ejecute el siguiente comando para resolver este problema.

Funcionó para mí.

chmod 600 ~/.ssh/id_rsa

Tuve el error al usar gpg-agent como mi ssh-agent y usar una subclave gpg como mi clave ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Sospecho que el problema fue causado por tener un tty de entrada de pin no válido para gpg causado por mi comando sleep + lock usado en mi configuración de balanceo

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

o solo el dormir / suspender

Restablezca la entrada del pin tty para solucionar el problema

gpg-connect-agent updatestartuptty /bye > /dev/null

y la solución para mi comando sway sleep + lock:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

A este error:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Verifique o agregue nuevamente la clave pública en Github account> profile> ssh.

Resolví así:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

Gracias.

Puede haber varias razones para obtener el error SSH:

sign_and_send_pubkey: la firma falló: el agente rechazó la operación

Algunos de ellos podrían estar relacionados con los problemas resaltados por las otras respuestas (vea las respuestas de este hilo), algunos de ellos podrían estar ocultos y, por lo tanto, requerirían una investigación más detallada.

En mi caso, tengo el siguiente mensaje de error:

sign_and_send_pubkey: la firma falló: el agente rechazó la operación

user@website.domain.com: Permiso denegado (clave pública, gssapi-keyex, gssapi-with-mic)

La única forma de encontrar el problema real era invocar la opción -v verbose que resultó en la impresión de mucha información de depuración:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

Tenga en cuenta que la línea que dice key_load_public: No such file or directory se refiere a la línea siguiente y no a la línea anterior.

Entonces, lo que SSH realmente dice es que no pudo encontrar el archivo de clave pública nombrado id_rsa.website.domain.com-certy ese parecía ser el problema en mi caso, ya que mi archivo de clave pública no contenía el -certsufijo.

En pocas palabras: la solución en mi caso fue solo asegurarme de que el archivo de clave pública tuviera el nombre esperado. Nunca podría sospechar eso sin depurar la conexión.

La conclusión es USE EL MODO SSH VERBOSE (opción -v) para averiguar qué está mal, puede haber varias razones, ninguna que se pueda encontrar en este / otro hilo.

Esta debería ser más bien una pregunta de superusuario.

Bien, tengo exactamente el mismo error dentro de MacOSX SourceTree, sin embargo, dentro de una terminal iTerm2, las cosas funcionan a la perfección.

Sin embargo, el problema parece ser que tengo dos ssh-agent s ejecutándose; (

El primero /usr/bin/ssh-agent(también conocido como MacOSX) y luego también el HomeBrew instalado en /usr/local/bin/ssh-agentejecución.

Encender un terminal desde SourceTree, me permitió ver las diferencias en SSH_AUTH_SOCK, al usar lsofencontré los dos diferentes ssh-agenty luego pude cargar las claves (usando ssh-add) en la configuración predeterminada del sistema ssh-agent(es decir /usr/bin/ssh-agent), SourceTree estaba funcionando nuevamente.

Si. Ejecute ssh-add en la máquina cliente. Luego repita el comando ssh-copy-id userserver@012.345.67.89

Para mí, el problema fue copiar / pegar incorrectamente la clave pública en Gitlab. La copia generó un retorno extra. Asegúrese de que lo que pega sea una clave de una línea.

También tengo un sign_and_send_pubkey: signing failed: agent refused operationerror. Pero en mi caso el problema fue un pinentrycamino equivocado .

En mi ${HOME}/.gnupg/gpg-agent.confla pinentry-programpropiedad estaba señalando un camino pinentry de edad. Corregir el camino allí y reiniciarlo lo gpg-agentarregló para mí.

Lo descubrí siguiendo los registros con journalctl -f. Allí donde las líneas de registro como las siguientes contienen la ruta incorrecta:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

Necesito compartir, ya que pasé demasiado tiempo buscando una solución.

Aquí estaba la solución: https://unix.stackexchange.com/a/351742/215375

Estaba usando este comando:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring no admite la clave generada.

Eliminar el -oargumento resolvió el problema.

En mi caso, el problema era que el llavero de GNOME contenía una frase de contraseña no válida para usar la clave ssh. Después de pasar una cantidad indecente de tiempo solucionando este problema, corrí seahorsey encontré que la entrada contenía una cadena vacía. Solo puedo adivinar que fue causado por escribir mal la frase de contraseña en el primer uso un tiempo antes, y luego probablemente cancele al solicitante para volver a la línea de comando. La actualización de la entrada con la contraseña correcta resolvió inmediatamente el problema. Eliminar esa entrada (del anillo de claves de "inicio de sesión") y volver a ingresar la frase de contraseña en el primer mensaje (y marcar la casilla de verificación correspondiente) también resuelve esto. Ahora el agente obtiene la contraseña correcta del llavero desbloqueado en el inicio de sesión llamado "login" y ya no solicita la contraseña ni "rechaza la operación". Por supuesto YMMV.

Qué funcionó aquí: en el cliente

1) ssh-agregar

2) ssh-copy-id usuario @ servidor

Las claves se crearon hace algún tiempo con "ssh-keygen -t rsa" llano. Le envié el mensaje de error porque copié a través de mi clave pública ssh del cliente al servidor (con ssh-id-copy) sin ejecutar ssh-add primero, ya que asumí erróneamente que los había agregado algún tiempo antes.

nota rápida para aquellos que se han actualizado recientemente a la versión "moderna" ssh [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 de septiembre de 2019] - suministrado con fedora 31, parece que ya no acepta claves DSA SHA256 antiguas (¡las mías están fechadas en 2006!) - Creé una nueva clave rsa, pública agregada a autorizada, privada en el cliente, y todo funciona perfectamente.

gracias por sugerencias anteriores, especialmente el ssh -v ha sido muy útil