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


110

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.

Respuestas:


195

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ó.


7
¡Caramba, pasé dos horas tratando de arreglar esto y esto es todo! Se corrigieron las conexiones ssh de bitbucket y aquia
Ronnie

18
No lo solucionó por completo aquí, ya que lo uso gpg-agentpara la funcionalidad SSH. Ya tengo una enable-ssh-supporten gpg-agent.confpero aún así mismo mensaje de error. He encontrado en la lista de correo para ejecutar esto gpg-connect-agent updatestartuptty /bye:: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394
Roland

1
Solo tenía que matar al agente gpg y luego ejecutarlo de nuevo.
Subin

3
Cuando genera una nueva clave SSH, ssh-adddebe invocarse para que se dé ssh-agentcuenta de la nueva clave privada (por linux.die.net/man/1/ssh-agent ).
alex

¡Excelente! He recreado mi clave SSH y esto comenzó a suceder. ¡Después de ssh-addque funcionó! Gracias.
hbobenicio

65

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/*

Mi .ssh/no tenía los permisos necesarios porque lo había creado yo mismo manualmente.
Brent Bradburn

1
Parece que algunas versiones no permiten que sus claves sean visibles para otros usuarios. ¡Gracias!
Alan Ocallaghan

si los archivos .ssh / * son creados por el mismo usuario (no root), no tenemos que preocuparnos, ya que tendrá los permisos necesarios.
Anto

1
Debo apreciarte. Encontré este problema hace un momento. Usar tu método lo resolvió.
Aterriza el

55

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.


3
Enfrenté este problema después de migrar Ubuntu de 16.04 LTS a 18.04 LTS, esta solución funcionó para mí.
Munish Chandel

Lo mismo aquí, después de actualizar Ubuntu a 18.04 enfrenté este problema. Esta solución lo arregla.
Cartucho

¿Cuándo id_rsa.pubse usa en el proceso de autenticación del cliente?
Dimitri Kopriwa

Si tiene muchas llaves, debe usar algo como esto en el interior ~/.ssh:chmod 600 id_*
lifeisfoo

10

Ejecute el siguiente comando para resolver este problema.

Funcionó para mí.

chmod 600 ~/.ssh/id_rsa

5

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'"


1
Gracias. Tuve este problema hace unos días, uso gpg como tú y he comentado gpg-connect-agent updaterstartuptty /bye > /dev/nullmi ~ / .zshrc, descomentar esta línea resolvió mi problema.
J.Adler

4

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.


2

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.


0

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.


0

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


0

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.


0

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


0

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.


0

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.


0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.