Ubuntu 16.04 ssh: sign_and_send_pubkey: firma fallida: el agente rechazó la operación

118

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

Después de instalar Ubuntu 16.04 recreé mis claves ssh porque olvidé respaldarlas, pero cada vez que intento usar ssh obtengo sign_and_send_pubkey: signing failed: agent refused operation esto es un poco molesto ya que me permite pasar a mi servidor ssh, pero git se rehúsa a presionar el código usando ssh.

Ya presioné 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 comando do-release-upgrade . Cualquier ayuda será muy apreciada.

    
pregunta Gamerb 25.04.2016 - 18:31

12 respuestas

227

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

ssh-add

Entonces puedes ssh en tu servidor.

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

ssh-add -l
    
respondido por el Ron 25.04.2016 - 18:52
25

Tuve el mismo problema (los mismos síntomas)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
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 resumen:

  1. Detecta el problema agregando SSH_AUTH_SOCK = 0 al frente del comando ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
  2. En caso de que tenga éxito para conectarse. Abra la aplicación StartUp Application (mediante 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 problemas similares con soluciones diferentes.

    
respondido por el sam 10.10.2016 - 08:59
14

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

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

Entonces todas mis llaves comenzaron a funcionar perfectamente.

ACTUALIZACIÓN:

Solución temporal sin desinstalar el llavero

Si quiere conservar el gnome-keyring y tiene el error agent refused operation , use:

eval 'ssh-agent -s'
ssh-add

o use SSH_AUTH_SOCK=0 ssh your-server

La solución permanente sin desinstalar el llavero

Si puedes, gnome-keyring es compatible con la clave RSA de 4096 bits, así que solo genera una nueva clave con:

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

Cargar clave pública en el servidor

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Agregar clave ssh al agente

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

Esto debería funcionar sin hacks adicionales y gnome-keyring puede permanecer instalado.

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

    
respondido por el Mike 26.04.2016 - 09:38
8

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

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

    
respondido por el Daniel Alder 11.06.2016 - 17:56
6

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

    
respondido por el qwertzguy 16.02.2017 - 02:02
6

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

    
respondido por el matthias 04.05.2018 - 17:44
6

Solución simple

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

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Los permisos de archivo eran demasiado abiertos (0644).

El siguiente comando lo resolvió:

chmod 600 .ssh/id_rsa
    
respondido por el Antonio Feitosa 31.05.2018 - 16:56
2

Agregando comentario ya que tuve el mismo problema con las claves ed25519. El problema es, de hecho, gnome-keyring. Para solucionar esto, hice lo siguiente:

  • Desmarcado ssh-key-agent (gnome-keyring) en "aplicaciones de inicio"
  • Expulsado del agente ssh-agent y gnome: (killall ssh-agent; killall gnome-keyring-daemon)
  • Reinició el daemon: (eval ssh-agent -s )
  • Agregue su clave: $ ssh-add id_ed25519 Ingrese la frase de contraseña para id_ed25519: Identidad agregada: id_ed25519
  • ¡Ganar!
respondido por el Matt 16.12.2016 - 16:03
2

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

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

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 está apuntando al problema real. Problema resuelto por

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
    
respondido por el Anto P Joseph 09.06.2018 - 12:15
0

Intenté un par de cosas, entre otras ssh-add, restablecer SSH (borrar .ssh / en el servidor, y tal, pero no tuve suerte. Resultó que solo tuve que dormir durante una noche. Creo que el ssh-agent que se ejecuta en el servidor tiene algo en su caché que se actualizó más tarde esa noche con los valores ahora adecuados. De todos modos, ahora funciona como un amuleto. Para concluir, lo hizo (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! :)
    
respondido por el untill 11.08.2016 - 10:12
0

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

    
respondido por el possumkeys 01.11.2016 - 08:46
0

Es a finales de 2018, y este error, o variaciones de él, todavía plagan a Xubuntu 16.04, y más que probable otros sabores de Xenial. ¡No me sorprendería si también existe en 18.04! Ha existido de alguna forma desde 2009, y Karmic Koala. Ha afectado a Redhat, Debian y Ubuntu. No confíe en mi palabra, vea las pistas públicas:

enlace

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

Referencias:

enlace

enlace

enlace

En mi caso, el síntoma más obvio era la incapacidad de usar claves ssh con frases de contraseña. Puede afectar también a los que no, ya que el mal funcionamiento impide que se carguen las claves ssh. Y no tenía problemas de permisos, todo era gnome-keyring. Mis claves (¡sí, rechazó varias, para diferentes servidores de SSH!) Fueron 600 (rw para el propietario, nada para el grupo u otro) como se indica en muchas respuestas al respecto. Entonces nada que pueda cambiar allí.

En Xubuntu, hay una forma de desactivar 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 deshabilitar el agente SSH, el agente GPG y otros elementos de Gnome que causan esto, y otros errores relacionados, apagué todos los elementos de inicio de Gnome. Puede ser exagerado o no una opción para algunos, ¡pero SSH ha vuelto a funcionar sin problemas en el próximo reinicio!

  1. Abre el menú principal de Whisker - & gt; Configuraciones - & gt; Sesión y inicio.
  2. Haga clic en la pestaña Avanzado, la última a la derecha.
  3. Deseleccione (apague) Inicie Servicios de Gnome al inicio.
  4. Cerrar y reiniciar. El cierre de sesión también puede hacerlo, pero debe reiniciarse con seguridad.

Captura de pantalla de la GUI descrita anteriormente:

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

Ubuntu ha fallado en aplastarlo definitivamente, ya que hay muchas entradas para varios lanzamientos que dicen que está arreglado, y más que dicen "regresión", está de vuelta.

Debian probablemente quiere despejarse (se lavan las manos) porque no son ellos, aguas arriba es Gnome.

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

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

    
respondido por el Lubo Diakov 23.07.2018 - 16:19

Lea otras preguntas en las etiquetas