que - ssh putty digitalocean

¿Cómo resolver "sign_and_send_pubkey: error de firma: el agente rechazó la operación"? (10)

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 [email protected] sign_and_send_pubkey: signing failed: agent refused operation [email protected]''s password:

El mensaje de error no señala el problema real. Problema resuelto por

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

Configuración de una nueva gota Digital Ocean con claves SSH. Cuando ejecuto ssh-copy-id esto es lo que obtengo:

ssh-copy-id [email protected] /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 [email protected]''s password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh ''[email protected]''" and check to make sure that only the key(s) you wanted were added.

Sin embargo, cuando intento ingresar, esto sucede:

ssh [email protected] sign_and_send_pubkey: signing failed: agent refused operation [email protected]''s password:

Al ingresar la contraseña, he iniciado sesión muy bien, pero esto, por supuesto, anula 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:

[email protected]:~# eval `ssh-agent -s` Agent pid 5715 [email protected]:~# ssh-add -l The agent has no identities.

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

Ejecute ssh-add en la máquina del cliente, que agregará la clave SSH al agente.

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

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

La forma de resolverlo es asegurándose de tener el permiso correcto en id_rsa e id_rsa.pub .

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

Para cambiar el permiso en los archivos use

chmod 600 id_rsa chmod 644 id_rsa.pub

Eso resolvió mi problema con la actualización.

Esto debería ser más bien una pregunta de Superusuario.

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

Sin embargo, el problema parece ser que tengo dos ssh-agent ejecución; (

El primero es /usr/bin/ssh-agent (también conocido como MacOSX''s) y luego también HomeBrew instaló /usr/local/bin/ssh-agent ejecución.

Al encender un terminal desde SourceTree, me permitió ver las diferencias en SSH_AUTH_SOCK , usando lsof encontré los dos ssh-agent diferentes y luego pude cargar las claves (usando ssh-add ) en el ssh-agent predeterminado del sistema ( es decir, /usr/bin/ssh-agent ), SourceTree estaba funcionando nuevamente.

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

Podría haber varias razones para obtener el error SSH:

sign_and_send_pubkey: error de firma: el agente rechazó la operación

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

En mi caso, recibo el siguiente mensaje de error:

sign_and_send_pubkey: error de firma: el agente rechazó la operación

[email protected]: Permiso denegado (publickey, gssapi-keyex, gssapi-with-mic)

La única forma de encontrar el problema real era invocar la opción detallada -v 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 hace referencia a la siguiente línea y no a la línea anterior.

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

Larga historia corta: la solución en mi caso fue solo asegurarme de que el archivo de clave pública se nombrara como se esperaba. Nunca podría sospechar eso sin depurar la conexión.

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

Sí. Ejecute ssh-add en la máquina del cliente. Luego repita el comando ssh-copy-id [email protected]

Tuve el error al usar gpg-agent como mi agente ssh y al 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 una entrada de PIN inválida tty para gpg causada por mi comando sleep + lock utilizado en mi configuración de sway

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

o solo el sueño / suspender

Restablezca la entrada de 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''"

sign_and_send_pubkey: signing failed: agent refused operation un sign_and_send_pubkey: signing failed: agent refused operation error de sign_and_send_pubkey: signing failed: agent refused operation . Pero en mi caso, el problema era un camino de pinentry incorrecto.

En mi ${HOME}/.gnupg/gpg-agent.conf la pinentry-program apuntaba a una ruta de pinentry antigua. Corregir la ruta allí y reiniciar el gpg-agent me lo arregló.

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

A este error:

# git pull sign_and_send_pubkey: signing failed: agent refused operation [email protected]: 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 la cuenta de Github> perfil> 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.