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

173

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.

Gamerb
fuente

Respuestas:

315

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
Ron
fuente
no es -1 (número <one>), es -l (L minúscula) en su segundo comando
Daniel Alder
3
@Daniel Alder De hecho, es minúscula l.
Ron
Tienes razón, lo siento. El problema es la minúscula Lde la fuente "Liberation Mono" :-(
Daniel Alder
1
No creo que deba usar ssh-addotra cosa que no sea para usar ssh-add -lporque puede terminar con demasiadas entradas en el ssh-agent. No hay necesidad de agregar manualmente. Dash > Startup Applicationsmuestra que ssh-agentya se está ejecutando y detectará automáticamente los archivos como ~/.ssh/id_rsay ~/.ssh/id_rsa.pub. Para probar esto, puede usar ssh-add -lantes y después de usar ssh-keygen. Verá que monitorea los archivos para que no tenga que agregarlos manualmente.
H2ONaCl
1
Del mismo modo, no utilice ssh-add -dy ssh-add -Dpara realizar la eliminación manual. Simplemente elimine los archivos de clave ~/.ssh/id_rsay ~/.ssh/id_rsa.pubya la ssh-agentnotificación voluntad. Para demostrar que puede hacerlo ssh-add -lantes y después de eliminar los archivos clave.
H2ONaCl
58

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
Antonio Feitosa
fuente
2
La ruta debe ser absoluta como esta: chmod 600 ~ / .ssh / id_rsa para que funcione en todos los casos.
Omar Alahmed
54

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.

sam
fuente
24
Su solución funcionó a medias para mí (un problema diferente con síntomas similares). Usando el paso 1 recibí el mensaje de error Permissions 0775 for '.ssh/id_rsa' are too open. La solución simple aquí era chmod 600 .ssh/id_rsa.
Matt
1
Esto también ayuda a depurar no solo la conexión de shell ssh sino también la autenticación git ssh. Usé este comando SSH_AUTH_SOCK=0antes git pully obtuve advertencias de permisos como Matt.
Serge
Me funcionó a mi también. Al parecer, la razón era que he cambiado comentario en mi llave y muy probablemente el agente gnomo llavero (también conocido como caballito de mar) seguía manteniendo la versión anterior en la memoria
maoizm
18

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)

Miguel
fuente
2
Sí, pero esto elimina toda la funcionalidad ssh-agent que es súper útil
Martin Konecny
tenga en cuenta en qué PC usar sudo apt-get, nuestra propia computadora o servidor remoto. Gracias.
Shicheng Guo
Keyring en su propia PC local, ya que Keyring es parte de GNOME, por lo general no está instalado en el servidor.
Mike
1
@MartinKonecny ​​bien, solo elimina el agente ssh proporcionado por gnome, no elimina el agente ssh simple y simple de la consola (si lo tiene instalado). El problema es que la variedad de gnomos se interpone en el camino de lo normal ssh-agent. Todavía puede iniciar ssh-agent e ingresar contraseñas de clave privada en la consola / shell.
blubberdiblub
Esto funciona si ha configurado iniciar sesión automáticamente en su DE sin ingresar su contraseña, porque de hecho su llavero de gnomo no se desbloqueará.
xjcl
14

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

Matías
fuente
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 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.

Daniel Alder
fuente
2
¿Y si los necesitas?
Gringo Suave
@GringoSuave Buena pregunta. ¿Has probado? Tal vez el formato cambió o ssh ya no lo admite, o es un error. Personalmente, estaba feliz de no tener que probarlo ...
Daniel Alder
Todavía no funciona para mí, no tengo solución: el Could not add identity "~/.ssh/id_ed25519": communication with agent failedagente se está ejecutando y configurado hasta donde puedo ver.
Gringo Suave
2
@GringoSuave la solución aquí también es deshacerse del agente de autenticación gnome que aplica un socket de agente en su shell en lugar del ssh-agentsocket simple . El agente ssh simple puede manejar claves ED25519 mientras que el agente de autenticación gnome no lo es (además de otros problemas que causa). Vea la respuesta de sam askubuntu.com/a/835114/167846 o Mike askubuntu.com/a/762968/167846
blubberdiblub el
7

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.

qwertzguy
fuente
6

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

neiltheory
fuente
Esto funcionó para mí, debería ser más votado
Sheshank S.
4

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/*
Anto
fuente
2

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!!
Mate
fuente
2

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:

Imagen

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!

Lubo Diakov
fuente
1

ssh-add

funciona para mi. Pero asegúrate

ssh-agent

Esta corriendo.

kst
fuente
1

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.

Norrius
fuente
0

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! :)
hasta
fuente
0

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.

zarigüeyas
fuente
0

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.

Fazliddin
fuente
0

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

Sam Brightman
fuente