Acabo de actualizar mi sistema Ubuntu de 15.10 a 16.04 limpiando completamente la partición Ubuntu 15 de mi sistema.

Después de instalar Ubuntu 16.04, recreé mis claves ssh ya que olvidé hacer una copia de seguridad, pero cada vez que intento usar ssh obtengo sign_and_send_pubkey: signing failed: agent refused operationesto es un poco molesto ya que me permite acceder a mi servidor ssh, pero git se niega a empujar el código usando ssh.

Ya he empujado las teclas al servidor usando ssh-copy-id.

El servidor al que me estoy conectando es un servidor Ubuntu 16.04 actualizado a través del do-release-upgradecomando. Cualquier ayuda será apreciada.

Parece ssh-agentque ya se está ejecutando pero no puede encontrar ninguna clave adjunta. Para resolver esto, agregue las identidades de clave privada al agente de autenticación de la siguiente manera:

ssh-add

Entonces puedes sshingresar a tu servidor.

Además, puede ver la lista de huellas digitales de todas las identidades agregadas actualmente por:

ssh-add -l

Solución simple

Tuve el mismo problema en Ubuntu 18.04. Eso es todo acerca de los permisos de clave privada del lado del cliente .

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation

Los permisos de archivo estaban demasiado abiertos (0644).

El siguiente comando lo resolvió:

chmod 600 ~/.ssh/id_rsa

Tuve el mismo problema (los mismos síntomas)

sam@xxxxx:~/.ssh$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... pero la solución fue diferente.

El problema provenía del uso de GNOME-KEYRING. La publicación que hace referencia a la solución se puede leer aquí .

En breve:

1. Detecte el problema agregando SSH_AUTH_SOCK = 0 delante del comando ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh [email protected]
2. En caso de que logre conectarse. Abra la aplicación StartUp Application (usando la función de búsqueda del escritorio, por ejemplo) y desactive el uso de gnome-keyring.
3. Reiniciar

La página proporciona otros detalles en caso de un problema similar con una solución diferente.

Obtuve el sign_and_send_pubkey: signing failed: agent refused operational iniciar sesión en varios servidores, leí la respuesta de VonC en Stack Overflow para obtener más información sobre errores relacionados, la solución para mí fue eliminar el llavero de gnome, eliminar identidades de ssh-agent y reiniciar.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Entonces todas mis llaves comenzaron a funcionar perfectamente.

ACTUALIZAR:

Solución temporal sin desinstalar llavero

Si desea mantener el llavero gnome y tiene el agent refused operationerror, use:

eval `ssh-agent -s`
ssh-add

o usar SSH_AUTH_SOCK=0 ssh your-server

La solución permanente sin desinstalar llavero

Si puede, el gnome-keyring es compatible con la clave RSA de 4096 bits, así que simplemente genere una nueva clave con:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Subir clave pública al servidor

$ ssh-copy-id -i ~/.ssh/your-key-name.pub [email protected]

Agregar clave ssh al agente

ssh-add ~/.ssh/your-key-name

Esto debería funcionar sin ningún truco adicional y gnome-keyring puede permanecer instalado.

(El -C [nombre de usuario] es opcional, pero es requerido por proveedores como Google Cloud)

Después de actualizar a Ubuntu 18.04, obtuve el mismo error sign_and_send_pubkey: signing failed: agent refused operation. Resulta que fue causado por los permisos de la clave ssh por estar demasiado abierta. El siguiente comando me solucionó el problema chmod 600 .ssh/id_rsa

En mi sistema (también Ubuntu 16.04, tratando de conectarme a github), tenía un archivo id_ed25519 en mi carpeta .ssh que ssh-addfalló:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

Después de eliminar los archivos ~/.ssh/id_ed25519*(ya no los necesitaba, era de una prueba anterior) todo volvió a funcionar bien.

Me pasó a mí porque mi clave privada tenía una frase de contraseña. Tuve que ejecutar ssh-addy luego solicitó la frase de contraseña y la agregó correctamente. Sin embargo, ahora no pide mi frase de contraseña cuando ssh'ing a una máquina.

Tengo una nueva instalación de Ubuntu16.04 y experimenté problemas similares. Cuando intenté clonar mi repositorio de Github después de haber copiado mi clave pública en github (según las instrucciones en github.com ) y después de realizar la siguiente verificación ( recomendada en github.com ):

ssh -T [email protected]

Fui recibido por lo siguiente:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Para solucionarlo rápidamente, sin quitar nada ni cambiar mi configuración de inicio, simplemente escribí lo siguiente en el terminal:

killall gnome-keyring-daemon

Entonces el clon funcionó. Luego comencé el demonio detenido nuevamente escribiendo:

gnome-keyring-daemon

Más tarde, para cambiar las cosas de una manera más permanente, seguí el consejo aquí.

Después de actualizar Fedora 26 a 28, enfrenté el mismo problema. Y no hay archivos de registro

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

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

Agregando comentarios ya que tuve el mismo problema con las claves ed25519. El problema es, de hecho, el llavero de gnomo. Para solucionar esto hice lo siguiente:

• Ssh-key-agent sin marcar (gnome-keyring) en "aplicaciones de inicio"
• Eliminó el agente ssh y el agente gnome: (killall ssh-agent; killall gnome-keyring-daemon)
• Reinició el demonio: (eval ssh-agent -s)
• Agregue su clave: $ ssh-add id_ed25519 Ingrese la frase de contraseña para id_ed25519: Identidad agregada: id_ed25519
• ¡¡Lucro!!

Es a finales de 2018, y este error, o variaciones de él, todavía afecta a Xubuntu 16.04, y es muy probable que tenga otros sabores de Xenial. ¡No me sorprendería si también existiera en 18.04! Ha existido de alguna forma desde 2009, y Karmic Koala. Ha afectado a Redhat, Debian y Ubuntu. No tome mi palabra, vea los rastreadores de errores públicos:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

Y en ese error, también encontrará listados para los otros 3:

Referencias

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

En mi caso, el síntoma más obvio fue la incapacidad de usar claves ssh con frases de contraseña. También puede afectar a los que no lo tienen, ya que el mal funcionamiento evita que se carguen las teclas ssh. Y no tuve problemas de permisos, todo era un llavero de gnomo. Los permisos de mis claves (sí, rechazó varios, ¡para diferentes servidores SSH!) Fueron 600 (rw para el propietario, nada para el grupo u otro) como se indica en muchas respuestas al respecto. Así que nada podría cambiar allí.

En Xubuntu, hay una manera de deshabilitar los elementos de inicio. Por lo general, también es posible en Unity / Gnome / KDE, pero no los tengo instalados, por lo que no puedo dar pasos específicos. No estoy seguro de otros escritorios. En lugar de desactivar el agente SSH, el agente GPG y otros elementos de Gnome que causan este y otros errores relacionados, apagué todos los elementos de inicio de Gnome. Puede ser excesivo o no una opción para algunos, pero SSH ha vuelto a funcionar sin problemas en el próximo reinicio.

1. Abra el Menú principal de Bigotes -> Configuración -> Sesión e inicio.
2. Haga clic en la pestaña Avanzado, la última a la derecha.
3. Desmarque (apague) Inicie Gnome Services al inicio.
4. Cierra y reinicia. Cerrar sesión también puede hacerlo, pero el reinicio debería ser seguro.

Captura de pantalla de la GUI descrita anteriormente:

Entonces, dado que di mi solución anterior, espero que alguien la arregle.

Probablemente, Ubuntu no ha podido aplastarlo para siempre, ya que hay muchos tickets para varios lanzamientos que afirman que está solucionado, y más que dicen "regresión", está de vuelta.

Debian probablemente quiera despejar (lavarse las manos) porque no son ellos, aguas arriba está Gnome.

Redhat probablemente tiene una solución solo disponible para clientes que pagan. Porque, históricamente, Redhat es el mayor empleador de desarrolladores de Gnome pagos, lo cual es generoso a primera vista. Hasta que se dé cuenta de que eso significa que tienen un incentivo financiero para nunca poner soluciones como esta en las versiones gratuitas, para seguir vendiendo suscripciones de Redhat.

Gnome es probablemente el que puede solucionarlo más fácilmente, y luego los demás pueden probar y empaquetar, sin escribir una línea de código. ¡Pero las entradas que leí dicen que el paquete ha languidecido durante años sin un responsable oficial! Y las dos personas que lo hacen voluntariamente ahora (gracias) están casi tan ocupadas diseñando un reemplazo. ¿Por qué no reparar una rueda pinchada incluso si lleva un año (ha pasado una década!) En lugar de reinventar la rueda primero!

ssh-add

funciona para mi. Pero asegúrate

ssh-agent

Esta corriendo.

En mi caso, el problema fue causado por GNOME Keyring. Para deshabilitar las capacidades SSH de gnome-keyring sin eliminarlo por completo (lo que rompe muchas cosas), siga estas instrucciones :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

y reinicie la sesión. Ahora puede ejecutar ssh-agent sin interferir el gnome-keyring.

Intenté un par de cosas, entre otras, ssh-add, restableciendo SSH (eliminando .ssh / en el servidor, y demás, pero no tuve suerte. Así que resultó que solo tuve que dormir una noche. ¡Ayudó! "Supongo que el agente ssh que se ejecuta en el servidor tenía algo en su caché que se actualizó más tarde esa noche con los valores ahora correctos. De todos modos, ahora funciona de maravilla. Para concluir, hizo esto (Ubuntu 16.04 en localhost, 14.04 en el servidor).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

Terminé soltando mi archivo de hosts conocidos y funcionó. Tuve que ingresar una contraseña nuevamente, pero finalmente aceptó la contraseña correcta. Fue después de una nueva instalación.

Si agregar SSH_AUTH_SOCK = 0 antes de que el comando ssh ayude, entonces es un error de llavero gnome. Excepto las soluciones y problemas proporcionados, el problema puede estar relacionado con la frase de contraseña. Si tiene una frase de contraseña para la clave, el llavero de gnome le pregunta cuándo inicia sesión por primera vez y si ingresa vacío por error o cierra la ventana inesperadamente, gnome lo asume como frase de contraseña vacía y lo recuerda para siempre. Nada ayuda a que se le solicite nuevamente la frase de contraseña. Para resolver, abra la aplicación ssh keyring y vaya a la sección Iniciar sesión en la categoría Contraseñas. Encuentre el registro correspondiente a la clave problemática e ingrese a Propiedades e ingrese la frase de contraseña correcta.

Hay otra causa de esto que todavía no se encuentra en ninguna respuesta: el formato PEM para el archivo de clave dejó de ser el predeterminado ssh-keygenantes de que Ubuntu se moviera a un gnome-keyring-daemonformato compatible con el nuevo formato RFC4716.

Si genera una nueva clave, o agrega / elimina una frase de contraseña de su clave, puede romperse. La clave se usa ssh-keygen -m PEMantes que cualquier otra operación que necesite ejecutar. Por ejemplo, puede volver a convertir al formato anterior utilizando ssh-keygen -m PEM -pe ingresando la frase de contraseña anterior como la nueva frase de contraseña (que estaría vacía sin frase de contraseña).